Der Artikel ist lang. Das ist Absicht: Er soll die Antwort ersetzen, nicht ergänzen. Lest quer, springt in die Stufe, die euch gerade betrifft, und nehmt den Rest, wenn ihr so weit seid.

Warum „Privatsphäre schützen" keine Liste mit zehn Apps ist

Die verbreitetste Form dieses Ratschlags ist eine Aufzählung: Nimm diesen Browser, dieses VPN, diesen Messenger, fertig. Das Problem daran ist nicht, dass die Empfehlungen falsch wären. Das Problem ist, dass sie ohne Reihenfolge kommen — und dass die meisten Leute deshalb bei Punkt drei aufhören, mit einem VPN-Abo, einem halb eingerichteten Messenger und weiterhin demselben Passwort auf vierzig Seiten.

Warum es sich überhaupt lohnt, haben wir in der Infozentrale ausgebreitet — das ist die Seite für alle, die erst noch überzeugt werden wollen. Hier setzen wir voraus, dass ihr überzeugt seid, und kümmern uns um das Wie.

Die erste Frage lautet: vor wem?

Fachleute nennen das ein Bedrohungsmodell, und das klingt nach mehr, als es ist. Es bedeutet nur: aufschreiben, wer sich für eure Daten interessiert und was passieren würde, wenn er sie bekommt. Die Antwort fällt sehr unterschiedlich aus, und daran hängt alles Weitere.

Für die allermeisten geht es um kommerzielle Profilbildung: Werbenetzwerke, Datenhändler, die Auswertung von Standort, Kaufverhalten und Kontakten. Dagegen hilft technische Hygiene, und zwar erstaunlich gut. Für andere geht es um staatlichen Zugriff — dann wird es unbequemer, weil Rechtsräume ins Spiel kommen. Der CLOUD Act und FISA Section 702 erklären, warum „liegt auf einem Server in Zürich" nichts heisst, solange der Anbieter amerikanisch ist. Und wer wissen will, was aus solchen Daten am Ende gebaut wird, findet das in unserem Stück über Palantir.

Ein dritter Fall wird oft übersehen und ist der häufigste von allen: Leute, die euch kennen. Ein Ex-Partner, ein neugieriger Nachbar, ein Kollege mit Zugriff auf euren entsperrten Rechner. Dagegen hilft kein VPN, sondern eine Bildschirmsperre, eine verschlüsselte Festplatte und ein Passwortmanager.

Drei Leute, drei Antworten

Die Familie mit NAS im Keller. Fotos, Steuerunterlagen, Kalender. Grösstes Risiko ist nicht der Geheimdienst, sondern der Ausfall der Festplatte und ein aus dem Internet erreichbares NAS-Login ohne zweiten Faktor. Priorität: Backups und Zugangsschutz.

Der Selbständige mit Kundendaten. Hier kommt eine rechtliche Dimension dazu — Kundendaten in einer amerikanischen Cloud sind ein Thema, das euch irgendwann jemand stellt. Priorität: wissen, wo die Daten liegen, und die wichtigsten Dienste in die eigene Hand nehmen.

Wer einfach genug hat vom Ausgewertetwerden. Kein akutes Risiko, aber der begründete Wunsch, nicht mehr Rohstoff zu sein. Priorität: Smartphone und Browser, weil dort die meisten Daten anfallen.

Wenn ihr euch in keinem davon wiederfindet: auch gut. Nehmt trotzdem Stufe 1, die gilt für alle.

Die Reihenfolge, in der sich der Aufwand lohnt

Wir sortieren nach einem einzigen Kriterium: Wirkung geteilt durch Aufwand. Deshalb steht der Passwortmanager vor dem entgoogelten Smartphone, obwohl das Smartphone das grössere Datenleck ist. Der Manager ist an einem Abend erledigt und schützt sofort; der Gerätewechsel ist ein Wochenende und ein bisschen Gewöhnung.

Wer die Stufen überspringt, baut auf Sand. Ein GrapheneOS-Telefon mit dem Passwort „Sommer2024!" auf allen Konten ist kein sicheres Setup, sondern ein teures.

Stufe 1: die Grundlagen, die für alle gelten

Diese Stufe kostet zusammen etwa einen Abend und wirkt bei jedem, egal welches Gerät, egal welches Betriebssystem. Wenn ihr nur eine Stufe macht, macht diese.

Ein Passwortmanager, und zwar nur einer

Der grösste einzelne Gewinn im ganzen Artikel. Nicht weil Passwörter spannend wären, sondern weil das Gegenteil so verheerend ist: Ein Passwort, das ihr auf mehreren Seiten benutzt, ist genau so sicher wie die schlechteste dieser Seiten. Und irgendeine davon wird gehackt — nicht vielleicht, sondern irgendwann.

Wie das praktisch läuft, steht in unserer Anleitung zu Bitwarden. Wer den Tresor nicht bei einem Anbieter liegen haben will, nimmt Vaultwarden, eine quelloffene, zu den Bitwarden-Apps kompatible Serverfassung — die ist ausdrücklich für Selbstbetrieb gedacht, weil das offizielle Serverpaket dafür zu schwer ist. Und wer sie weder mieten noch selbst betreiben mag: Wir betreiben eine, sie ist kostenlos nutzbar, und ihr könnt jederzeit exportieren und gehen.

Drei Regeln, mehr braucht es nicht: ein langes, einzigartiges Hauptpasswort, das ihr euch merkt. Alle anderen Passwörter erzeugt der Manager und ihr seht sie nie. Und den Notfallzugang — Wiederherstellungscodes, Exportdatei — druckt ihr aus und legt ihn dorthin, wo ihr auch euren Pass aufbewahrt.

Zwei Faktoren, ohne Google

Ein zweiter Faktor macht ein gestohlenes Passwort weitgehend wertlos. Nur bitte nicht per SMS, wenn es sich vermeiden lässt: Eine Rufnummer lässt sich mit erstaunlich wenig Aufwand übernehmen. Nehmt eine App, die die Codes lokal erzeugt — Aegis tut genau das, ist quelloffen und lässt sich verschlüsselt sichern. Der Google Authenticator kann dasselbe, verlangt dafür aber ein Google-Konto, was hier eher gegen den Zweck arbeitet.

Bei Passkeys lohnt ein zweiter Blick, bevor ihr umstellt: Sie sind technisch gut und binden euch gleichzeitig enger an eine Plattform. Was dafür und was dagegen spricht, haben wir in Passkeys — Vor- und Nachteile auseinandergenommen.

Browser und Suchmaschine

Der Browser ist das Werkzeug, mit dem ihr die meisten Spuren hinterlasst. Firefox mit einer Handvoll Erweiterungen deckt den grössten Teil ab; welche das sind, steht in Die besten Extensions für den Firefox Browser. Wer weiter gehen will, findet in Firefox absichern mit AppArmor und user.js die härtere Fassung.

Ein häufiger Anfängerfehler ist dabei, es zu gut zu meinen. Zwanzig Datenschutz-Erweiterungen machen euren Browser nicht anonymer, sondern einzigartiger — und damit besser wiedererkennbar. Warum das so ist, erklärt Browser-Fingerprinting. Wenig und dafür richtig schlägt viel.

Praktisch im Alltag sind ausserdem Multi-Account-Container: Damit sitzt das soziale Netzwerk in einem eigenen Abteil und sieht nicht, was ihr sonst noch aufmacht. Bei der Suchmaschine gibt es mehr Auswahl, als die meisten denken — unsere fünf Alternativen zur Google-Suche gehen die Kandidaten durch, und weil die Frage regelmässig kommt: Sammelt Mozilla Daten oder zensiert DuckDuckGo? ordnet die üblichen Vorwürfe ein.

Nebenbei: Selbst eine Schriftart kann petzen. Google Fonts lädt bei jedem Seitenaufruf nach — und überträgt dabei eure IP-Adresse an Google, ohne dass ihr etwas anklickt.

DNS: die Spur, an die niemand denkt

Jedes Mal, wenn euer Gerät eine Adresse aufruft, fragt es zuerst einen Namensserver, wo die Seite liegt. Diese Anfragen laufen standardmässig unverschlüsselt und beim Internetanbieter — eine vollständige Liste eurer Aufrufe, ganz ohne Cookies. Das lässt sich in zehn Minuten abstellen, und die Anleitung dazu deckt alle drei Systeme ab: DNS-Verschlüsselung auf Linux, Android und Windows.

Einen passenden Server müsst ihr nicht suchen: Wir betreiben einen freien DNS-Server in der Schweiz, mit Verschlüsselung und Filterlisten gegen Werbung und Tracker. Wer lieber im eigenen Netz filtert, findet in Pi-hole auf dem Raspberry Pi den Weg dorthin — das wirkt dann auch auf Geräten, die sich nicht konfigurieren lassen, vom Fernseher bis zur Waschmaschine.

Backups, und zwar vor allem anderen

Das klingt nach dem falschen Thema, ist aber die Voraussetzung für alles, was danach kommt. Wer bei einem Systemwechsel Angst um seine Daten hat, macht den Wechsel nicht — und bleibt aus lauter Vorsicht bei dem, was ihn ausliest. Ein geprüftes Backup ist die Erlaubnis, Dinge auszuprobieren.

Die Grundregel steht in Was ist ein gutes Backup: die 3-2-1-Regel erklärt. Drei Kopien, zwei verschiedene Medien, eine ausser Haus. Und die einzige Frage, auf die es ankommt: Habt ihr schon einmal versucht, aus diesem Backup etwas zurückzuholen? Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.

Betrugsmails erkennen

Die meisten Konten gehen nicht durch technische Angriffe verloren, sondern weil jemand seine Zugangsdaten auf einer nachgebauten Seite eingibt. Unsere Übersicht zu Betrugs-, Phishing-Mails und SMS zeigt die Merkmale. Die wirksamste Gewohnheit ist dabei simpel: Links in Mails grundsätzlich nicht anklicken, sondern die Seite selbst im Browser aufrufen. Kostet drei Sekunden und erledigt die halbe Kategorie.

Stufe 2: das Smartphone ist die grösste Wanze

Es ist immer dabei, es kennt euren Standort, eure Kontakte, eure Gewohnheiten und eure Uhrzeiten. Kein anderes Gerät liefert ein so vollständiges Bild. Deshalb ist es die Stufe mit dem grössten Hebel — und leider auch die mit der grössten Umstellung.

Der konsequente Weg: ein Gerät ohne Google

Ein alternatives Android-Betriebssystem ersetzt die Herstellerfassung durch eine, die ohne Google-Dienste läuft. Warum das mehr bringt als jede Einstellung im Google-Konto, steht auf unserer Seite Googlefreie Smartphones; welche Systeme es gibt und wie sie sich unterscheiden, in Welches CustomROM?.

Die beiden Systeme, die wir empfehlen, sind GrapheneOS und CalyxOS. GrapheneOS ist die härtere Wahl und läuft ausschliesslich auf Pixel-Geräten — das Projekt begründet das in seiner FAQ damit, dass Geräte nach ihren Eigenschaften ausgewählt werden und nicht nach möglichst breiter Abdeckung. Wer Google-Apps trotzdem braucht, kann sie dort als normale, eingesperrte App nachinstallieren, statt sie im System zu haben. Unser GrapheneOS-Einsteiger-Guide führt durch die Einrichtung, und Hat Google Zugriff auf Pixel-Phones mit GrapheneOS? beantwortet die Frage, die dabei jeder stellt.

CalyxOS unterstützt daneben auch Fairphone- und Motorola-Geräte; die aktuelle Geräteliste führt das Projekt selbst, gestaffelt nach Unterstützungsdauer. Der CalyxOS-Einsteiger-Guide zeigt die Einrichtung. Ob euer Gerät überhaupt in Frage kommt, klärt vorher unsere Kompatibilitätsliste — nicht jedes Telefon lässt sich entsperren, und ohne entsperrbaren Bootloader endet die Sache, bevor sie anfängt.

Zwei Systeme, die im Netz oft empfohlen werden, empfehlen wir ausdrücklich nicht, und wir haben beides begründet: Warum Murenas /e/OS eine Mogelpackung ist und VollaOS: Datenschutz-Marketing gegen technische Realität. Datenschutz auf der Verpackung ist keine Eigenschaft des Produkts.

Der kleine Weg: beim Gerät bleiben und aufräumen

Nicht jeder will oder kann das Gerät wechseln. Das ist kein Grund, gar nichts zu tun — es bringt nur weniger, und das gehört ehrlich dazugesagt. Der Weg für Geräte, die bei der Herstellerfassung bleiben, steht in Privatsphäre auf Android schützen: Aktivitätsverläufe abschalten, personalisierte Werbung deaktivieren, Standortberechtigungen pro App durchgehen.

Deutlich weiter kommt ihr mit unserem zweiteiligen Workshop Android zähmen: Debloating und Firewalling. Vorinstallierte Apps loswerden, ohne das Gerät zu rooten, und einzelnen Apps den Netzzugang entziehen — dafür braucht es keine neue Firmware. Eine lokale Firewall wie ReThink zeigt euch nebenbei zum ersten Mal, wie oft eure Apps eigentlich nach Hause telefonieren. Diese Liste ist für die meisten ein Erlebnis.

Und eine Kleinigkeit mit grosser Wirkung, die auf jedem Gerät funktioniert: WLAN-Tracking unterbinden. Ein Telefon, das ständig nach bekannten Netzen ruft, lässt sich quer durch eine Innenstadt verfolgen.

Apps ohne Play Store

Ein Telefon ohne Google-Konto braucht einen anderen Weg zu Apps. Drei Wege haben sich bewährt, und sie schliessen sich nicht aus.

F-Droid ist ein Katalog ausschliesslich freier Software — das Projekt beschreibt sich selbst als vertrauenswürdiger Weg, quelloffene Android-Apps zu finden und zu teilen. Die Einrichtung steht in F-Droid Installation und Anwendung, und weil das Projekt nicht unumstritten ist, haben wir die Sicherheitsbedenken ebenfalls aufgeschrieben statt sie zu übergehen.

Für Apps, die es nur im Play Store gibt, gibt es den Aurora Store — der holt sie ohne eigenes Google-Konto. Und Obtainium zieht Apps direkt von der Seite des Entwicklers und hält sie aktuell, was besonders bei Software praktisch ist, die in keinem Katalog steht. Womit ihr euer Telefon dann füllt, steht in Die besten Android Open Source Apps.

Ein Hinweis, der in den nächsten Monaten wichtig wird: Google baut die App-Verteilung um und verlangt künftig, dass Entwickler sich verifizieren lassen — auch für Apps, die nie durch den Play Store laufen. Was das bedeutet, steht in Android-Entwickler-Verifizierung: euer Gerät ist egal. Das ist kein Grund, jetzt nichts zu tun, aber ein Grund, die Entwicklung im Auge zu behalten.

Benachrichtigungen ohne Google Push

Hier scheitern die meisten Umsteiger, und zwar an etwas Unerwartetem: Die Nachrichten kommen nicht mehr an. Der Grund ist, dass fast jede App ihre Benachrichtigungen über Googles Push-Dienst schickt — der auf einem entgoogelten Gerät fehlt. Was dieser Dienst tut und was er dabei mitliest, steht in Was ist Google Push?.

Die Lösung heisst UnifiedPush: ein offener Ersatz, bei dem ihr bestimmt, über welchen Server die Benachrichtigungen laufen. Wir betreiben einen, den ihr kostenlos eintragen könnt. Für Signal braucht es zusätzlich einen kleinen Vermittler, und auch den stellen wir bereit. Die Einrichtung auf dem Gerät zeigen Molly FOSS mit UnifiedPush und Element ohne Google Push.

Die Standardapps ersetzen

Karten, Videos, Gerätesuche — für alles, was ihr täglich benutzt, gibt es einen Ersatz, der ohne Konto auskommt.

Bei der Gerätesuche gilt derselbe Gedanke wie beim Push: Ihr braucht einen Server, der die Standortmeldungen entgegennimmt. Auch den betreiben wir kostenlos, damit dieser eine fehlende Baustein nicht den ganzen Umstieg blockiert.

Was ihr beim Umzug nicht verliert

Die häufigste Sorge vor dem Wechsel: „Und meine Bilder? Und die Kontakte? Und die zwölf Jahre WhatsApp?" Der Umzug ist gelöst, und zwar schriftlich. Daten auf ein CustomROM übertragen deckt den Hauptteil ab, Kontakte und SMS von Android oder iPhone übertragen den Rest — auch von einem iPhone aus.

Für danach: Ein CustomROM lokal sichern und wiederherstellen. Macht das einmal, bevor ihr es braucht.

Stufe 3: der Computer

Auf dem Rechner ist der Hebel kleiner als beim Telefon — er ist nicht immer dabei und weiss weniger über euren Tagesablauf. Dafür ist der Umstieg technisch einfacher und leichter rückgängig zu machen.

Warum Linux, und für wen nicht

Die Argumente stehen auf unserer Seite Warum Linux. Die Kurzfassung: kein Telemetrie-Kanal, den ihr nicht abschalten könnt, keine Werbung im Startmenü, keine Konto-Pflicht — und ein zehn Jahre alter Laptop, der wieder benutzbar wird. Wie das aussieht, zeigt Alte Computer mit Linux wieder fit machen.

Ehrlich bleiben gehört dazu: Wer beruflich auf Adobe, bestimmte CAD-Programme oder eine Branchensoftware angewiesen ist, wird damit unter Linux keine Freude haben. Das ist ein Argument gegen Linux auf diesem Rechner, kein Argument gegen Linux. Ein zweiter, älterer Laptop für alles Private ist oft die bessere Lösung als ein halbherziger Komplettumstieg.

Welche Distribution — und erst einmal ausprobieren

Bevor ihr irgendetwas installiert: Linux online ausprobieren kostet nichts und braucht keinen USB-Stick. Danach hilft Welches Linux passt zu mir bei der Auswahl, ausführlicher wird es in Welches Linux-Betriebssystem?. Ob eure Hardware mitspielt, klärt Auf welcher Hardware läuft Linux.

Für den eigentlichen Wechsel gibt es einen Leitfaden von vorne bis hinten: Umstieg von Windows auf Linux. Und die Frage, die immer als erste kommt, ist dort auch beantwortet: Braucht Linux einen Virenschutz?

Die Festplatte verschlüsseln

Der Punkt, der gegen die realistischste Bedrohung hilft: einen gestohlenen oder liegengelassenen Laptop. Ohne Verschlüsselung ist die Anmeldung am System nur eine Tür in einem Haus ohne Wände — die Platte lässt sich ausbauen und an einem anderen Rechner auslesen. Was LUKS ist und wann es sich lohnt, steht in Was ist LUKS, das nachträgliche Verschlüsseln in Home-Ordner nachträglich verschlüsseln. Für einzelne Container und für Windows-Rechner gibt es VeraCrypt.

Vor jedem dieser Schritte gilt Stufe 1: erst das Backup, dann die Verschlüsselung. In dieser Reihenfolge, nicht andersherum. Für den Rückweg nach einem missglückten Update ist TimeShift zuständig, für die regelmässige Sicherung Linux-PC lokal und auf NAS sichern.

Stufe 4: Kommunikation

Messenger: der Inhalt ist längst nicht das Problem

Fast alle grossen Messenger verschlüsseln die Inhalte inzwischen. Das ist gut und lenkt gleichzeitig von der eigentlichen Frage ab: Wer redet wann wie lange mit wem? Diese Metadaten sagen mehr aus als die meisten Gespräche selbst, und sie sind nicht verschlüsselt. Warum das so ist, steht in Metadaten bei Messengern — der wichtigste Artikel in diesem Abschnitt, auch wenn er der unbequemste ist.

Bei WhatsApp kommt hinzu, dass die Verschlüsselung weniger verspricht, als der Werbetext nahelegt; wir haben das in Warum WhatsApps Verschlüsselung eine Verarsche ist auseinandergenommen, und inzwischen beschäftigt die Frage auch ein Gericht.

Praktisch heisst das: Signal ist für die meisten der vernünftige Kompromiss — gute Verschlüsselung, wenig gespeicherte Metadaten, und alle Bekannten sind mit einer Rufnummer erreichbar. Wer die Rufnummer nicht hergeben will, landet bei Matrix, das ohne Telefonnummer auskommt und auf beliebigen Servern läuft. Wir betreiben einen öffentlichen Matrix-Server samt Weboberfläche; wie ihr dazukommt, steht auf unserer Chat-Seite. Dieselbe Logik in gross erklärt Was ist das Fediverse.

E-Mail

E-Mail ist alt, offen und wird das bleiben. Ein Anbieterwechsel bringt trotzdem einiges — unsere Übersicht der fünf privatsphäreorientierten Anbieter nennt die Kandidaten und ihre Haken. Wichtig zu wissen: Verschlüsselt ist damit die Verbindung und die Ablage beim Anbieter, nicht die Mail selbst. Dafür braucht es OpenPGP, auf dem Telefon entsprechend so. Das lohnt sich für einzelne Empfänger, nicht für den ganzen Posteingang — und wer es benutzt, braucht ein Gegenüber, das mitmacht.

Als Programm empfehlen wir Thunderbird auf dem Rechner und K-9 Mail auf dem Telefon. Für Anmeldungen bei Diensten, denen ihr nicht traut, haben wir einen Wegwerf-Mail-Dienst — mit einer wichtigen Einschränkung, die dort auch steht: Diese Postfächer sind öffentlich lesbar, sobald jemand die Adresse kennt. Für Newsletter und Einmal-Registrierungen gut, für alles andere nicht.

Videokonferenz

Für Besprechungen ohne Konto und ohne Installation gibt es Jitsi Meet. Unseren Server könnt ihr ohne Anmeldung benutzen: Link erzeugen, verschicken, fertig. Das ist der Punkt, an dem die meisten merken, dass „datenschutzfreundlich" nicht zwangsläufig „umständlich" heisst.

VPN und Tor: was sie leisten und was nicht

Diese beiden Werkzeuge werden häufiger empfohlen als verstanden, und sie stehen hier bewusst nicht in Stufe 1. Sie lösen ein eng umrissenes Problem sehr gut und alle anderen Probleme gar nicht.

Ein VPN verschiebt Vertrauen, es erzeugt keine Anonymität

Ein VPN sorgt dafür, dass euer Internetanbieter nicht mehr sieht, welche Seiten ihr aufruft. Stattdessen sieht es der VPN-Anbieter. Das ist ein Tausch, kein Zugewinn — und ob er sich lohnt, hängt allein davon ab, wem ihr weniger traut. Die ausführliche Fassung steht in Bin ich mit einem VPN anonym?. Kurz: nein. Wer bei Google angemeldet surft, ist mit VPN genau so identifiziert wie ohne, nur mit anderer IP-Adresse.

Sinnvoll ist ein VPN im fremden WLAN, gegen die Auswertung durch den eigenen Anbieter und für den Zugriff auf das eigene Netz von unterwegs. Und für diesen letzten Zweck — den mit Abstand häufigsten — braucht ihr gar keinen Anbieter, sondern einen eigenen Server: Wireguard betreiben oder, wenn ein NAS im Haus steht, den VPN-Server auf der Synology. Dann führt der Tunnel nach Hause statt zu einer Firma, deren Werbeversprechen niemand prüfen kann.

Tor

Tor löst das Problem, das ein VPN nicht löst: Es gibt keine einzelne Stelle, die gleichzeitig weiss, wer ihr seid und was ihr aufruft. Wie das funktioniert, steht in Was ist das Tor-Netzwerk. Den Tor Browser gibt es für Windows, macOS, Linux und Android; für iOS verweist das Projekt auf den Onion Browser.

Der ehrliche Teil: Tor ist langsam, manche Seiten sperren es aus, und es ist kein Zauber. Unsere technische Einordnung der BKA-Timing-Attacke zeigt, wo die Grenzen liegen — und auch, dass die Berichterstattung dazu deutlich dramatischer war als der Sachverhalt. Für Recherche, für Themen, bei denen euch niemand über die Schulter schauen soll, und für den Zugang zu gesperrten Inhalten ist Tor das richtige Werkzeug. Zum täglichen Einkaufen nicht.

Tor auf dem Smartphone: Orbot und der Tor Browser

Auf Android gibt es zwei Wege. Der Tor Browser leitet nur den Browser durch das Netz. Orbot geht weiter und legt sich als Tunnel vor das ganze Gerät oder wahlweise vor einzelne Apps — die Anleitung dazu steht in Orbot: Daten über das Tor-Netzwerk verschlüsseln. Wie ihr einzelne Messenger hindurchschickt, zeigt Telegram, Signal oder WhatsApp über Tor. Auf Linux macht Oniux dasselbe für einzelne Programme.

Eine Warnung, die viel Ärger erspart: Ein Konto, das euren Namen trägt, bleibt euer Konto — auch über Tor. Was das für die üblichen Plattformen bedeutet, steht in Kann ich Social Media anonym benutzen?.

Der NAS, den ihr vielleicht schon habt

Erstaunlich viele, die uns schreiben, haben bereits ein NAS im Keller stehen — meistens eine Synology. Das ist ein guter Ausgangspunkt und gleichzeitig das Gerät, bei dem am häufigsten etwas schiefliegt.

Vier Dinge, in dieser Reihenfolge. Erstens: Zwei-Faktor-Authentifizierung einschalten. Ein NAS-Login, das aus dem Internet erreichbar ist und nur ein Passwort hat, wird angegriffen — nicht vielleicht, sondern täglich und automatisiert. Zweitens: Das Verwaltungsinterface gehört nicht ins offene Internet. Nehmt stattdessen einen VPN-Zugang, dann ist das NAS von unterwegs erreichbar, ohne dass es die halbe Welt anschauen kann. Wer eine feste Adresse dafür braucht, findet sie in DynDNS für Synology.

Drittens: Ein externes Backup. Ein NAS ist kein Backup, auch nicht mit RAID — RAID schützt gegen eine kaputte Platte, nicht gegen Verschlüsselungstrojaner, Blitzschlag oder eine versehentlich gelöschte Ordnerstruktur. Viertens, wenn ihr Lust habt: Nextcloud auf der Synology. Damit ersetzt ein Gerät, das ihr schon habt, Google Drive, den Kalender und die Kontaktsynchronisation.

Für alle, die weiter aufteilen wollen: VLANs trennen das Heimnetz in Bereiche, sodass der smarte Fernseher nicht im selben Segment sitzt wie die Buchhaltung. Was ist eine Firewall liefert die Grundlagen dazu. Und wenn Daten trotz allem bei einem Cloud-Anbieter liegen müssen, hilft Daten in der Cloud verschlüsseln: Was verschlüsselt hochgeht, ist dem Anbieter egal.

Selber hosten oder nutzen, was schon läuft

An dieser Stelle kommt bei fast allen dieselbe Frage: Muss ich dafür jetzt einen Server betreiben? Nein. Es gibt drei Wege, und sie lassen sich beliebig mischen.

Weg eins: benutzen, was bei uns schon läuft

Wir betreiben über zwanzig Dienste auf eigenen Servern, überwiegend in der Schweiz, und sie sind kostenlos nutzbar — für Kundschaft wie für Leser. Die vollständige Liste steht auf Unsere Server für mehr Privatsphäre. Die für den Einstieg nützlichsten haben wir oben schon genannt; hier der Überblick.

• Nextcloud — Dateien, Kalender, Kontakte und Aufgaben. 4 GB für Leser, 10 GB für Kundschaft.
• Immich — Foto- und Videocloud mit automatischem Upload vom Telefon, 3 GB gratis.
• Vaultwarden — Passwortmanager, kompatibel mit den Bitwarden-Apps.
• Freier DNS-Server — verschlüsselt, mit Filterlisten.
• UnifiedPush und MollySocket — Benachrichtigungen ohne Google.
• Find My Device — Gerätesuche ohne Google-Konto.
• Jitsi Meet — Videokonferenz ohne Anmeldung.
• Matrix-Chatserver — Messenger ohne Telefonnummer.
• Dateiverschlüsselung im Browser — verschlüsseln, bevor etwas irgendwo hochgeht.
• Linkwarden für Lesezeichen und ein Übersetzer-Frontend ohne Konto.

Für die meisten dieser Dienste braucht ihr weder ein Konto noch eine Anmeldung bei uns; bei Nextcloud, dem Chatserver und einigen weiteren geht es nicht ohne. Wir verlangen dafür nichts und wir wollen dafür auch nichts — ausser vielleicht, dass ihr uns Bescheid gebt, wenn etwas nicht läuft.

Weg zwei: selbst hosten

Wer die Kontrolle wirklich will, betreibt die Dienste selbst — auf einem Mini-PC, einem Raspberry Pi oder dem NAS, das ohnehin schon läuft. Was Nextcloud ist und was es ersetzt, erklärt unsere Seite Was ist Nextcloud. Der übliche Unterbau dafür ist Docker, und den Einstieg dazu liefert Docker Basics.

Zwei Dinge braucht ihr fast immer. Erstens einen Reverse Proxy, damit die Dienste unter ordentlichen Adressen und mit gültigen Zertifikaten erreichbar sind: Caddy einrichten. Zweitens eine Aufgabenplanung, die euch meldet, wenn eine Sicherung nicht durchgelaufen ist — dafür haben wir gerade erst systemd-Timer statt Cronjob geschrieben. Und wenn ihr schon dabei seid, den Papierkram gleich mit: Paperless-ngx einrichten macht aus dem Ordner mit den Rechnungen ein durchsuchbares Archiv, das im Haus bleibt.

Ehrlicherweise gehört dazu: Selbst hosten heisst, dass ihr ab jetzt der Systemadministrator seid. Updates, Backups, ein Dienst, der um drei Uhr nachts stehenbleibt. Das ist machbar und für viele sogar unterhaltsam — aber es ist eine Verpflichtung und kein einmaliger Nachmittag.

Weg drei: einrichten lassen

Wenn ihr das Ergebnis wollt, aber nicht den Weg dorthin, machen wir das. Was wir installieren und wie das abläuft, steht auf Open-Source-Services für euer Zuhause oder euer Unternehmen — von der Beratung über die Hardware bis zur Einweisung, für Privathaushalte wie für kleinere Betriebe, vor Ort oder aus der Ferne. Der praktische Vorteil des Wegs: Ihr könnt sämtliche Dienste vorher auf unseren Servern ausprobieren und erst danach entscheiden, was ihr davon bei euch stehen haben wollt.

Eine Bitte in eigener Sache: Für persönliche Einrichtungsfragen per Mail fehlt uns schlicht die Zeit — es sind zu viele. Was es dafür gibt, ist unser Chatserver, und der funktioniert erfahrungsgemäss besser als eine Mail an uns: Dort sitzen Leute, die dieselbe Umstellung vor sechs Monaten hinter sich gebracht haben. Wir sind auch dort unterwegs.

Die Fehler, die wir am häufigsten sehen

Alles auf einmal. Neues Telefon, neues Betriebssystem, neuer Messenger, neuer Mailanbieter, alles an einem Wochenende. Danach funktioniert irgendetwas nicht, und weil vier Dinge gleichzeitig neu sind, findet niemand mehr heraus, welches. Eine Sache pro Woche reicht völlig.

Das VPN zuerst. Es ist die sichtbarste Massnahme und deshalb die beliebteste. Nur ändert sie am wenigsten, solange die Grundlagen fehlen.

Werbung glauben statt nachschauen. „Datenschutzfreundlich" ist keine geschützte Bezeichnung und kostet in der Herstellung genau nichts. Unsere Artikel zu /e/OS und VollaOS zeigen den Unterschied zwischen Versprechen und Nachprüfung.

Kein Rückweg eingeplant. Bevor ihr ein Telefon neu aufsetzt oder eine Platte verschlüsselt: Backup, und einmal testweise zurückgeholt. Wer diesen Schritt überspringt, spart zwanzig Minuten und riskiert einen Abend.

Die eigenen Leute vergessen. Der beste Messenger nützt nichts, wenn niemand aus eurem Umfeld ihn benutzt. Rechnet damit, dass ihr zwei Anwendungen parallel führt — das ist kein Scheitern, sondern der Normalfall.

Perfektion als Ziel. Es gibt kein vollständig spurenfreies digitales Leben, jedenfalls keines, in dem sich noch angenehm leben lässt. Achtzig Prozent weniger Datenspur bei zwanzig Prozent Aufwand ist ein hervorragendes Ergebnis. Wer die letzten zwanzig Prozent erzwingen will, hört meistens ganz auf — und landet wieder bei hundert.

Womit ihr diese Woche anfangt

Nicht alles, sondern das hier. Vier Abende, verteilt über eine Woche, und ihr habt den grössten Teil der Wirkung mitgenommen.

• Abend 1 — Passwörter. Passwortmanager einrichten, Hauptpasswort festlegen, die zehn wichtigsten Konten umstellen: Mail zuerst, dann Bank, dann der Rest. Die restlichen dreissig macht ihr nebenbei, immer wenn ihr euch irgendwo anmeldet.
• Abend 2 — zweiter Faktor und DNS. Aegis installieren und bei Mail und Bank den zweiten Faktor einschalten. Danach die DNS-Verschlüsselung auf Telefon und Rechner setzen. Zusammen gut eine Stunde.
• Abend 3 — Backup. Einen Sicherungsplan aufsetzen und, das ist der eigentliche Punkt, einmal eine Datei daraus zurückholen. Erst dann habt ihr ein Backup und nicht nur ein Programm.
• Abend 4 — Browser. Firefox mit wenigen, ausgewählten Erweiterungen einrichten, Suchmaschine wechseln, Container für die grossen Plattformen anlegen.

Danach, in Ruhe und in dieser Reihenfolge: das Smartphone, dann der Rechner, dann die Kommunikation. Und wenn ihr wissen wollt, ob sich der Umstieg auf ein anderes Telefon oder auf Linux für euch überhaupt lohnt, ist unser FAQ der schnellste Weg zu einer Antwort — dort stehen die neunundzwanzig Fragen, die Umsteiger tatsächlich stellen, jeweils mit der passenden Anleitung dahinter.

Fazit: Privatsphäre ist eine Reihenfolge, kein Produkt

Es gibt keinen Kauf, der diese Frage erledigt, und keine App, nach deren Installation ihr fertig seid. Es gibt eine Handvoll Gewohnheiten, ein paar Werkzeuge und die Bereitschaft, alle paar Monate einen weiteren Schritt zu machen. Das ist die unspektakuläre Wahrheit hinter einem Thema, zu dem sehr viel spektakulär geschrieben wird.

Die gute Nachricht daran ist, dass der grösste Teil des Gewinns am Anfang steht. Passwortmanager, zweiter Faktor, verschlüsseltes DNS und ein Backup, das funktioniert — das ist ein Abend Arbeit und bringt mehr als jedes VPN-Abo. Der Rest darf dauern.

Und noch etwas: Ihr müsst das nicht allein machen und ihr müsst es nicht perfekt machen. Jeder Dienst, den ihr nicht mehr benutzt, ist ein Profil, das nicht weiterwächst. Das zählt auch dann, wenn drei andere noch laufen.

Quellen und weiterführende Links

Der Ratgeber ist bewusst als Verteiler gebaut. Hier alles noch einmal nach Thema sortiert, damit ihr diesen Abschnitt allein weitergeben könnt.

Warum überhaupt

• Infozentrale — die Ausgangslage
• Der CLOUD Act und FISA Section 702 — warum der Serverstandort allein nichts sagt
• Palantir, die Sehsteine der USA in Europa

Stufe 1: Grundlagen

• Passwortmanager Bitwarden · Vaultwarden (Projekt) · unser Vaultwarden
• Aegis als zweiter Faktor · Passkeys: Vor- und Nachteile
• Firefox-Erweiterungen · Firefox härten · Browser-Fingerprinting · Multi-Account-Container
• Suchmaschinen-Alternativen · Mozilla und DuckDuckGo eingeordnet · Google Fonts
• DNS verschlüsseln · unser DNS-Server · Pi-hole
• Die 3-2-1-Regel · Phishing erkennen

Stufe 2: Smartphone

• Googlefreie Smartphones · Welches CustomROM? · Kompatibilitätsliste
• GrapheneOS FAQ · GrapheneOS-Guide · Hat Google Zugriff?
• CalyxOS Geräteliste · CalyxOS-Guide
• Nicht empfohlen, mit Begründung: /e/OS · VollaOS
• Beim Gerät bleiben: Privatsphäre auf Android · Android zähmen · ReThink-Firewall · WLAN-Tracking
• Apps: F-Droid (Projekt) · F-Droid einrichten · F-Droid: Sicherheitsbedenken · Aurora Store · Obtainium · Die besten Open-Source-Apps · Entwickler-Verifizierung
• Push: Was ist Google Push · Molly FOSS · Element ohne Google Push
• Umzug: Daten übertragen · Kontakte und SMS · Lokale Sicherung · Backup mit Nextcloud
• Ersatz-Apps: Organic Maps · NewPipe · Gerät orten ohne Google

Stufe 3: Computer

• Warum Linux · Linux online ausprobieren · Welches Linux passt zu mir · Welches Linux-Betriebssystem?
• Umstiegs-Leitfaden · Hardware · Alte Rechner · Virenschutz?
• Verschlüsselung und Sicherung: LUKS · Home-Ordner verschlüsseln · VeraCrypt · TimeShift · Sicherung auf NAS

Stufe 4: Kommunikation

• Metadaten bei Messengern · WhatsApp-Verschlüsselung · der Gerichtsfall dazu
• Unser Chatserver · Matrix-Server · Element im Browser · Was ist das Fediverse
• E-Mail: Anbieterübersicht · OpenPGP · OpenPGP auf Android · Thunderbird · K-9 Mail · Wegwerf-Mail
• Jitsi Meet ohne Konto

VPN und Tor

• Bin ich mit einem VPN anonym? · Wireguard selbst betreiben · VPN auf der Synology
• Was ist das Tor-Netzwerk · Tor Browser (Projekt) · BKA-Timing-Attacke eingeordnet
• Orbot (Projekt) · Orbot einrichten · Messenger über Tor · Oniux unter Linux · Social Media anonym?

NAS, eigene Dienste und Einrichtung

• Synology: Zwei-Faktor · DynDNS · externes Backup · Nextcloud auf der Synology
• Netz: VLANs · Firewall · Cloud-Daten verschlüsseln
• Selbst hosten: Was ist Nextcloud · Docker Basics · Caddy · systemd-Timer · Paperless-ngx
• Unsere Angebote: alle kostenlosen Dienste · Einrichtung bei euch
• Weiterlesen: FAQ für Umsteiger · alle Anleitungen · Privacy-Tipps

The post Privatsphäre schützen: der Ratgeber für den Einstieg appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Warum systemd-Timer den Cronjob ablösen

Cron macht genau eine Sache: Es startet zur eingetragenen Zeit einen Befehl. Was danach passiert, interessiert es nicht. Läuft der Befehl auf einen Fehler, landet die Ausgabe im besten Fall in einer lokalen Mail, die niemand liest, und im schlechteren Fall in /dev/null, weil das jemand vor drei Jahren so eingetragen hat, damit das Log nicht zuläuft. Wie diese Umleitung funktioniert, haben wir in stdout, stderr und /dev/null auseinandergenommen – bei Cron ist sie der häufigste Grund, warum ein Fehlschlag unbemerkt bleibt.

Falls ihr Cron bisher klassisch benutzt habt, etwa für die Hintergrundaufgaben einer Nextcloud, kennt ihr die Bedienung aus unserer Anleitung Cronjob für Eure Nextcloud erstellen. Alles, was dort steht, funktioniert weiterhin. Es gibt nur eben inzwischen einen zweiten Weg.

Amazon ist dabei am deutlichsten geworden. In der Dokumentation zu Amazon Linux 2023 steht schwarz auf weiss: „In AL2023, cronie is not included by default. Therefore, support for crontab is no longer provided by default." Und weiter: „We recommend that you migrate to systemd timers due to the added functionality provided by systemd." Nachzulesen in der AL2023-Dokumentation zu Cron. Auf Debian, Ubuntu und Mint ist Cron weiterhin installiert – aber ein wachsender Teil der Systemwartung läuft dort ohnehin schon über Timer-Units, ohne dass es jemand gemerkt hätte.

Der praktische Unterschied lässt sich in eine Tabelle packen:

Die letzte Zeile ist der ehrliche Teil. Wer alle fünf Minuten ein Einzeiler-Skript anstossen will und sonst nichts, ist mit Cron schneller fertig. Für alles, dessen Ausfall wehtut – Sicherungen, Zertifikatserneuerungen, Datenbankpflege – lohnt sich der Mehraufwand ab dem ersten stillen Fehlschlag.

Voraussetzungen und eine Vorwarnung

Ihr braucht ein System mit systemd. Das trifft auf Debian, Ubuntu, Linux Mint, Fedora, openSUSE und Arch zu, also auf praktisch alles, was auf dieser Seite sonst behandelt wird. Prüfen lässt sich das mit:

systemctl --version

Für Units im Systemkontext braucht ihr Root-Rechte. Alle folgenden Befehle mit sudo setzen voraus, dass euer Benutzer das darf. Wer sich bei Benutzern, Gruppen und Rechten unsicher ist, findet die Grundlagen in Linux Gruppen und Berechtigungen einfach erklärt.

Wichtig: Legt eigene Units immer unter /etc/systemd/system/ ab, niemals unter /lib/systemd/system/ oder /usr/lib/systemd/system/. Das zweite Verzeichnis gehört der Paketverwaltung, und das nächste Update überschreibt eure Datei kommentarlos.

Die zwei Dateien: eine Service-Unit und eine Timer-Unit

Ein systemd-Timer führt selbst nichts aus. Er ist ausschliesslich der Wecker; die Arbeit macht eine Service-Unit. Die Handbuchseite systemd.timer(5) beschreibt die Zuordnung so: Ein Timer namens foo.timer aktiviert standardmässig die Unit foo.service, also den gleichen Namen mit anderer Endung. Solange ihr beide Dateien gleich benennt, müsst ihr die Verbindung nirgends eintragen.

Als durchgehendes Beispiel dient eine nächtliche Sicherung des Home-Verzeichnisses. Das eigentliche Skript liege unter /usr/local/bin/backup-home.sh und sei ausführbar.

Schritt 1: Die Service-Unit anlegen

sudo nano /etc/systemd/system/backup-home.service

Inhalt:

[Unit]
Description=Naechtliche Sicherung des Home-Verzeichnisses
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-home.sh
User=mario
Nice=10
IOSchedulingClass=idle

Drei Zeilen verdienen eine Erklärung. Type=oneshot ist der Typ für Aufgaben, die anlaufen, ihre Arbeit tun und sich beenden. Laut systemd.service(5) betrachtet der Dienstmanager die Unit erst dann als gestartet, wenn der Hauptprozess sich beendet hat – „the service manager will consider the unit up after the main process exits". Genau das wollt ihr hier, denn eine Sicherung ist fertig oder nicht.

User=mario lässt das Skript unter eurem Benutzer laufen statt als Root – ersetzt den Namen, und lasst die Zeile weg, falls das Skript Root braucht. Nice=10 und IOSchedulingClass=idle drängen den Job hinter interaktive Arbeit zurück; die Sicherung darf zehn Minuten länger dauern, wenn dafür niemand ruckelt.

Es fehlt eine Zeile, die ihr aus Cron kennt: die Umleitung der Ausgabe. Die braucht es nicht. Alles, was das Skript auf stdout und stderr schreibt, landet ohne Zutun im Journal – so beschreibt es systemd.exec(5) im Abschnitt zu Logging und Standard-Ein- und -Ausgabe.

Schritt 2: Die Timer-Unit anlegen

sudo nano /etc/systemd/system/backup-home.timer

Inhalt:

[Unit]
Description=Startet die naechtliche Home-Sicherung

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=900
AccuracySec=1min

[Install]
WantedBy=timers.target

Der Abschnitt [Install] mit WantedBy=timers.target ist der Grund, warum der Timer nach einem Neustart wieder da ist. Fehlt er, lässt sich die Unit zwar starten, aber nicht dauerhaft aktivieren.

Schritt 3: Einlesen und aktivieren

sudo systemctl daemon-reload
sudo systemctl enable --now backup-home.timer

daemon-reload lädt die Konfiguration des Dienstmanagers neu; laut systemctl(1) werden dabei alle Unit-Dateien neu eingelesen und der gesamte Abhängigkeitsbaum neu aufgebaut. Ohne diesen Schritt kennt systemd eure Datei nicht. enable --now aktiviert die Unit und startet sie in einem Aufwasch.

Beachtet: Aktiviert wird der Timer, nicht der Service. Der Service bleibt inaktiv und wird vom Timer geweckt. Ein häufiger Anfängerfehler ist systemctl enable backup-home.service – damit läuft die Sicherung bei jedem Systemstart genau einmal und danach nie wieder.

Testen lässt sich der Ablauf jederzeit, ohne auf zwei Uhr nachts zu warten:

sudo systemctl start backup-home.service
systemctl status backup-home.service

Damit ist die Grundkonstruktion fertig. Wie die drei beteiligten Units zusammenspielen – die dritte kommt weiter unten dazu – zeigt das folgende Schaubild.

OnCalendar: die Zeitsyntax, die kein Cron-Format ist

Hier liegt die grösste Umgewöhnung. OnCalendar= benutzt nicht die fünf Sternchen aus der Crontab, sondern eine eigene Schreibweise. Die Handbuchseite systemd.time(7) beschreibt das Format als Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde. Der Wochentag darf fehlen, das Datum ebenso; die Uhrzeit ist der Kern.

Die Operatoren sind schnell erzählt. Ein Sternchen passt auf jeden Wert. Mehrere Werte werden mit Komma aufgezählt. Zwei Punkte bilden einen Bereich, etwa Mon..Fri. Der Schrägstrich bedeutet Wiederholung, also *:0/15 für alle fünfzehn Minuten.

Zusätzlich gibt es Kurzformen, die die Handbuchseite ausdrücklich als Abkürzungen ausweist:

Ein paar praktische Ausdrücke, die die meisten Fälle abdecken:

OnCalendar=*-*-* 02:00:00          # jede Nacht um 02:00
OnCalendar=Mon..Fri *-*-* 07:30    # werktags um 07:30
OnCalendar=Sun *-*-* 04:00:00      # sonntags um 04:00
OnCalendar=*-*-01 03:00:00         # am Ersten jedes Monats um 03:00
OnCalendar=*:0/15                  # alle 15 Minuten
OnCalendar=hourly                  # zur vollen Stunde

Mehrere OnCalendar=-Zeilen in derselben Unit sind erlaubt und ergeben mehrere Auslösezeitpunkte. Eine leere Zuweisung OnCalendar= löscht alle bisherigen Angaben – nützlich in Drop-in-Dateien, verwirrend, wenn es unbeabsichtigt passiert.

Den Ausdruck prüfen, bevor ihr ihn einsetzt

Ihr müsst nicht raten. systemd-analyze hat einen Unterbefehl, der genau dafür da ist. Die Handbuchseite systemd-analyze(1) beschreibt ihn so: „This command will parse and normalize repetitive calendar time events, and will calculate when they elapse next."

systemd-analyze calendar "Mon..Fri *-*-* 07:30"

Die Ausgabe nennt die ursprüngliche Form, die normalisierte Form, den nächsten Auslösezeitpunkt und den Abstand bis dahin. Steht dort ein Datum, das euch überrascht, habt ihr euch vertan – und das vor dem Produktivbetrieb statt danach. Verwandt und ebenso nützlich ist systemd-analyze verify /etc/systemd/system/backup-home.service: Der Befehl meldet unbekannte Abschnitte, fehlende Abhängigkeiten und nicht ausführbare Befehle.

Kalenderausdrücke werden in der lokalen Zeitzone des Systems ausgewertet. Auf einem Server, der auf UTC steht, ist „02:00" also nicht eure Bettzeit – ein Blick auf timedatectl vor dem ersten Timer erspart Verwunderung.

Persistent, RandomizedDelaySec und der Rest der Feineinstellung

Die vier Zeilen aus dem Beispiel sind der Punkt, an dem ein Timer den Cronjob inhaltlich überholt. Alle stammen aus dem Abschnitt [Timer] und sind in systemd.timer(5) beschrieben.

Persistent=true speichert den letzten Auslösezeitpunkt auf der Platte. War das System zum geplanten Termin aus, wird der Job unmittelbar nach dem Hochfahren nachgeholt. Das ist die Funktion, für die es unter Cron ein zweites Programm braucht – anacron –, und auf einem Laptop, der nachts um zwei zugeklappt im Rucksack liegt, ist sie der Unterschied zwischen einer Sicherung und einer Sicherungsabsicht.

RandomizedDelaySec=900 verzögert die Ausführung um eine zufällig gewählte, gleichmässig verteilte Zeitspanne zwischen null und dem angegebenen Wert. Wenn zwanzig Maschinen um Punkt zwei Uhr dieselbe Netzwerkfreigabe ansteuern, verteilt das die Last über eine Viertelstunde. Wollt ihr die Verzögerung stabil statt bei jedem Start neu ausgewürfelt, setzt zusätzlich FixedRandomDelay=true: Der Versatz wird dann aus Maschinen-ID und Unit-Namen abgeleitet und bleibt gleich. Wie stark eure Maschine unter solchen Spitzen tatsächlich leidet, seht ihr mit den Werkzeugen aus Nützliche Linux Konsolen Tools für das Systemmonitoring.

AccuracySec= gibt an, wie genau der Timer treffen soll, und steht laut Handbuch standardmässig auf einer Minute. systemd nutzt diese Toleranz, um Aufwachvorgänge zu bündeln und den Rechner länger schlafen zu lassen. Wer es exakt braucht, setzt AccuracySec=1us – und zahlt das mit Stromverbrauch.

Drei weitere Optionen sind gut zu kennen. OnBootSec= definiert einen Zeitpunkt relativ zum Systemstart, OnUnitActiveSec= einen relativ zur letzten Aktivierung der Zieleinheit. Kombiniert ergibt das „fünf Minuten nach dem Start und danach alle sechs Stunden", ohne jeden Kalender:

[Timer]
OnBootSec=5min
OnUnitActiveSec=6h

Und WakeSystem=true weckt das System aus dem Bereitschaftsbetrieb, wenn der Timer fällig wird. Auf einem Server irrelevant, auf einem Heim-NAS mit Ruhezustand entscheidend.

Soll der Timer eine Unit mit abweichendem Namen starten, gebt sie ausdrücklich an – Unit= ist laut Handbuch „the unit to activate when this timer elapses". Nötig ist das nur, wenn ihr von der Namenskonvention abweicht.

Nachsehen, ob es läuft: list-timers und das Journal

Der wichtigste Befehl im Alltag ist eine Übersicht aller Timer, sortiert nach dem nächsten Auslösezeitpunkt:

systemctl list-timers backup-home.timer

Die Ausgabe sieht so aus:

NEXT                 LEFT      UNIT               ACTIVATES
Do 2026-09-03 02:14  19h left  backup-home.timer  backup-home.service

Die Spalten sind in systemctl(1) beschrieben: NEXT zeigt, wann der Timer das nächste Mal läuft, LEFT wie lange es bis dahin dauert, LAST und PASSED dasselbe rückwärts, UNIT den Namen des Timers und ACTIVATES den Dienst, den er startet. Ohne Argument listet der Befehl alle Timer des Systems auf – der schnellste Weg zu sehen, was auf einer fremden Maschine eigentlich alles nachts passiert. systemctl list-timers --all zeigt zusätzlich die inaktiven.

Die 02:14 in der Ausgabe sind übrigens kein Tippfehler: Das ist RandomizedDelaySec bei der Arbeit.

Was der Job beim letzten Lauf gesagt hat, steht im Journal. Die Option -u filtert laut journalctl(1) auf die Meldungen einer bestimmten Unit:

journalctl -u backup-home.service -n 50 --no-pager
journalctl -u backup-home.service --since "-7d" -p warning
journalctl -u backup-home.service -f

Die erste Zeile zeigt die letzten fünfzig Meldungen, die zweite alle Warnungen und Schlimmeres der vergangenen sieben Tage, die dritte hängt sich live an die Ausgabe und läuft bis Strg+C. Wer tiefer in die Fehlersuche einsteigen will, findet den Rest in unserer Anleitung Linux Problembehebung im systemd.

Nützlich ist ausserdem systemctl cat backup-home.timer: Der Befehl zeigt die Unit so, wie systemd sie tatsächlich sieht, samt allen Drop-ins – und beendet jede Diskussion darüber, welche der drei Kopien nun gilt.

Der eigentliche Gewinn: OnFailure meldet den Fehlschlag

Bis hierhin habt ihr einen Cronjob mit mehr Schreibarbeit. Der Unterschied beginnt jetzt. In systemd.unit(5) steht eine Option, die es unter Cron schlicht nicht gibt: OnFailure= ist „a space-separated list of one or more units that are activated when this unit enters the 'failed' state." Anders gesagt: Geht die Sicherung schief, startet systemd von sich aus eine zweite Unit eurer Wahl. Was diese Unit tut, ist euch überlassen – eine Push-Nachricht, eine Mail, ein Eintrag in ein Monitoring.

Eine Benachrichtigungs-Unit als Vorlage anlegen

Damit ihr die Unit nicht für jeden Job neu schreibt, legt ihr sie als Vorlage an. Der Klammeraffe im Dateinamen macht daraus eine Template-Unit, deren Instanzname später den Namen des fehlgeschlagenen Dienstes trägt.

sudo nano /etc/systemd/system/alarm@.service

[Unit]
Description=Meldet den Fehlschlag von %i per ntfy

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -sS \
  -H "Title: Fehlgeschlagen: %i" \
  -H "Priority: 5" \
  -H "Tags: warning" \
  -d "Auf diesem System ist %i fehlgeschlagen. Details mit: journalctl -u %i -n 50" \
  https://ntfy.sh/EUER-LANGES-ZUFALLSTHEMA

Der Platzhalter %i ist in systemd.unit(5) als Instance name definiert: die Zeichenkette zwischen dem ersten @ und der Endung. Ihr braucht die Unit also genau einmal, egal wie viele Jobs sie später melden soll.

Prüft, ob curl überhaupt installiert ist, und ob der Pfad stimmt:

which curl

Liegt es woanders, tragt den tatsächlichen Pfad ein. ExecStart= verlangt einen absoluten Pfad und findet nichts über die PATH-Variable.

Die Vorlage im Job eintragen

Ergänzt den Abschnitt [Unit] eurer Service-Unit um eine Zeile:

[Unit]
Description=Naechtliche Sicherung des Home-Verzeichnisses
Wants=network-online.target
After=network-online.target
OnFailure=alarm@%n.service

%n ist laut Handbuch der full unit name, hier also backup-home.service. Aus alarm@%n.service wird damit die Unit alarm@backup-home.service.service, und in der Benachrichtigung steht %i für backup-home.service. Das sieht auf den ersten Blick nach einem Tippfehler aus und ist genau richtig so.

sudo systemctl daemon-reload

ntfy einrichten und den Alarm testen

ntfy verschickt Push-Nachrichten über einen einfachen HTTP-Aufruf. Die Projektdokumentation zeigt den Aufbau: Der Nachrichtentext geht per -d an eine URL, deren letzter Bestandteil das Thema ist; Titel, Priorität und Schlagwörter werden über die Kopfzeilen Title, Priority und Tags gesetzt. Priorität 5 ist die höchste von fünf Stufen.

Sicherheitshinweis, und der ist ernst gemeint: Bei ntfy gibt es keine Anmeldung für das blosse Senden und Empfangen. Die Projektdokumentation formuliert das unmissverständlich: „the topic is essentially a password", ihr sollt also etwas wählen, das nicht zu erraten ist. Wer backup als Thema nimmt, teilt seine Ausfallmeldungen mit der halben Welt. Nehmt eine lange Zufallszeichenkette, zum Beispiel erzeugt mit head -c 18 /dev/urandom | base64 | tr -d '/+='. Wer den Dienst nicht in fremden Händen haben will, betreibt ntfy selbst – der Server ist quelloffen und in einem Container schnell aufgesetzt.

Installiert die ntfy-App auf dem Smartphone, abonniert dort euer Thema und löst dann absichtlich einen Fehler aus. Am einfachsten geht das mit einer Wegwerf-Unit:

sudo systemd-run --unit=alarmtest --property=OnFailure=alarm@alarmtest.service /bin/false

/bin/false beendet sich mit einem Fehlerstatus, die Unit geht damit in den Zustand failed, und das Telefon sollte klingeln. Kommt nichts an, prüft zuerst die Benachrichtigungs-Unit selbst:

journalctl -u "alarm@*" -n 30 --no-pager

Wollt ihr statt einer Push-Nachricht eine Mail, ersetzt den curl-Aufruf durch ein Skript, das systemctl status %i und journalctl -u %i -n 50 einsammelt und an sendmail oder msmtp übergibt. Der Mechanismus bleibt derselbe; systemd interessiert sich nicht dafür, was die Unit tut, sondern nur dafür, dass sie startet. Für Erfolgsmeldungen gibt es das Gegenstück OnSuccess=, ausgelöst beim Wechsel in den Zustand inactive.

Timer ohne Root: der Benutzerkontext

Nicht jede Aufgabe gehört ins Systemverzeichnis. Alles, was nur euer Benutzer betrifft – Mails abholen, ein Verzeichnis synchronisieren, eine Datensicherung eures Home – lässt sich im Benutzerkontext ablegen. Die Dateien liegen dann unter ~/.config/systemd/user/, und sämtliche Befehle bekommen --user und kein sudo:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/backup-home.service
nano ~/.config/systemd/user/backup-home.timer
systemctl --user daemon-reload
systemctl --user enable --now backup-home.timer
systemctl --user list-timers

Zwei Anpassungen sind nötig. Erstens entfällt die Zeile User=, denn der Dienst läuft ohnehin unter euch. Zweitens lautet der Abschnitt [Install] hier WantedBy=default.target statt timers.target.

Und dann kommt die Falle, über die alle einmal stolpern: Benutzer-Units werden standardmässig beendet, sobald ihr euch abmeldet. Auf einem Server, an dem ihr euch nur zum Arbeiten anmeldet, läuft der Timer damit praktisch nie. Abhilfe schafft „Lingering", beschrieben in loginctl(1): „If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts."

sudo loginctl enable-linger mario
loginctl user-status mario

Ersetzt den Benutzernamen. Ab jetzt startet der Benutzermanager beim Systemstart und bleibt nach dem Abmelden bestehen. Rückgängig macht das sudo loginctl disable-linger mario.

Das Journal des Benutzers lest ihr mit journalctl --user -u backup-home.service. Ohne --user sucht ihr an der falschen Stelle und findet nichts – ein Fehler, der schon manchen an seinem Verstand hat zweifeln lassen.

Ein bestehendes Backup umstellen

Der häufigste Anwendungsfall ist die Sicherung. Wer nach unserer Anleitung Linux PC lokal und auf NAS sichern mit Borg arbeitet, hat den Zeitplan bisher in der Oberfläche von Vorta hängen – was voraussetzt, dass die grafische Sitzung läuft. Ein Timer löst dieselbe Aufgabe unabhängig von Anmeldung und Desktop.

Das Vorgehen in vier Schritten: den Ablauf in ein Skript unter /usr/local/bin/ giessen und von Hand ausführen, bis er sauber durchläuft; Service- und Timer-Unit wie oben anlegen; OnFailure= eintragen und den Alarm testen; zuletzt den alten Cron-Eintrag entfernen – crontab -e für den Benutzer, sudo crontab -e für Root, dazu ein Blick in /etc/cron.d/. Wer den alten Eintrag stehen lässt, hat zwei Sicherungen, die sich um dasselbe Verzeichnis streiten.

Ein Wort zum Rückgabewert: systemd erkennt einen Fehlschlag daran, dass der Prozess mit einem Status ungleich null endet. Ein Shell-Skript, das brav exit 0 ans Ende schreibt oder dessen Fehler in einer Pipe verschwinden, meldet niemals einen Fehler – und dann nützt das schönste OnFailure= nichts. Setzt an den Anfang eures Skripts set -euo pipefail, dann bricht es bei einem Fehler ab und gibt ihn weiter.

Wenn etwas nicht klappt

Der Timer taucht in list-timers nicht auf. Entweder fehlt daemon-reload, oder der Timer ist nur gestartet und nicht aktiviert, oder im Abschnitt [Install] fehlt WantedBy=. Prüft mit systemctl is-enabled backup-home.timer.

Der Timer läuft, aber nichts passiert. Wahrscheinlich stimmt die Namenspaarung nicht. Der Timer backup-home.timer sucht backup-home.service; heisst eure Service-Datei anders, tragt Unit= im Abschnitt [Timer] ein. Die Spalte ACTIVATES in list-timers verrät, was er tatsächlich zu starten versucht.

Die Unit geht sofort in failed, Status 203/EXEC. Der Pfad in ExecStart= stimmt nicht oder die Datei ist nicht ausführbar. Absoluter Pfad ist Pflicht, und chmod +x hilft.

Status 217/USER oder 226/NAMESPACE. Der in User= angegebene Benutzer existiert nicht, oder ihm fehlt der Zugriff auf ein Verzeichnis. Prüft den Namen und die Rechte des Zielpfads.

Das Skript läuft von Hand, aber nicht als Unit. Der Klassiker. Units erben eure Shell-Umgebung nicht: kein PATH wie im Terminal, keine Variablen aus .bashrc, kein SSH-Agent, kein DISPLAY. Schreibt absolute Pfade und setzt benötigte Variablen mit Environment= oder EnvironmentFile= in der Unit.

Der Job läuft nachts nicht, weil der Rechner aus war. Dafür ist Persistent=true da. Bei einem Gerät im Ruhezustand hilft zusätzlich WakeSystem=true.

Der Benutzer-Timer läuft nur, solange ihr angemeldet seid. sudo loginctl enable-linger BENUTZER, siehe oben.

Der Alarm kommt nicht an. Prüft mit journalctl -u "alarm@*", ob die Benachrichtigungs-Unit überhaupt gestartet ist. Wurde sie gestartet und curl meldet einen Fehler, fehlt meist die Netzwerkverbindung zum Zeitpunkt des Fehlschlags oder das Thema ist falsch geschrieben. Steht in der Ausgabe gar nichts, wurde OnFailure= nicht ausgelöst – dann endet euer Skript vermutlich mit Status null, obwohl es gescheitert ist.

Fazit: Ein Job, der schweigt, ist kein Job

Der Mehraufwand gegenüber einer Cron-Zeile ist real und überschaubar: zwei Dateien statt einer Zeile, eine ungewohnte Zeitsyntax, ein Befehl zum Neuladen. Dafür bekommt ihr eine geplante Aufgabe, die sich wie jeder andere Dienst abfragen lässt, deren Ausgabe automatisch im Journal steht, die einen verpassten Termin nachholt und die euch anruft, wenn sie gescheitert ist.

Der letzte Punkt ist der einzige, auf den es wirklich ankommt. Eine Sicherung, von der ihr nicht wisst, ob sie läuft, ist keine Sicherung, sondern eine Hoffnung mit Speicherplatzbedarf. Cron kann euch das nicht sagen, weil es dafür nie gebaut wurde. Ein Timer mit OnFailure= kann es, und der Aufwand dafür beträgt sechs Zeilen.

Fangt mit dem einen Job an, dessen Ausfall euch stören würde, und stellt genau den um. Der Rest darf in Ruhe folgen – oder bei Cron bleiben. Es ist keine Glaubensfrage, sondern eine Frage danach, was passieren soll, wenn etwas schiefgeht.

Quellen und weiterführende Links

• systemd.timer(5) – Handbuchseite zu Timer-Units: OnCalendar, Persistent, RandomizedDelaySec, AccuracySec, WakeSystem, Unit
• systemd.time(7) – Kalenderausdrücke, Kurzformen und Zeitspannen
• systemd.unit(5) – OnFailure, OnSuccess und die Platzhalter %i und %n
• systemd.service(5) – Type=oneshot, ExecStart, RemainAfterExit, SuccessExitStatus
• systemd.exec(5) – Logging sowie Standard-Ein- und -Ausgabe von Units
• systemctl(1) – list-timers mit den Spalten NEXT, LEFT, LAST, PASSED, UNIT, ACTIVATES sowie daemon-reload und cat
• systemd-analyze(1) – die Unterbefehle calendar, timespan und verify
• journalctl(1) – die Optionen -u, --since, -p, -f und --user
• loginctl(1) – enable-linger, disable-linger und user-status
• ntfy: Sending messages – Aufbau des Publish-Aufrufs, Kopfzeilen Title, Priority und Tags, Hinweis zur Vertraulichkeit des Themas
• Amazon Linux 2023: Cron und systemd-Timer – Begründung für den Verzicht auf cronie
• Cronjob für Eure Nextcloud erstellen – der klassische Weg mit crontab
• Linux Problembehebung im systemd – Fehler im System mit journalctl eingrenzen
• stdout, stderr und /dev/null – warum Cron-Ausgaben so oft verschwinden
• Linux PC lokal und auf NAS sichern – Borg und Vorta als Praxisbeispiel

The post systemd-Timer statt Cronjob: einrichten und überwachen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der BLAKE2b-Hard-Fork kam zwei Tage früher als angekündigt

Den Anfang machte eine öffentliche Warnung. Am 29. August, 11:54 Uhr, schrieb Luke Dashjr: "PSA: Potential Bitcoin PoW change Sunday. SHA2 miners should stop mining Saturday." Bitcoin Knots 29.4.1rc4 werde am Tag darauf erscheinen und den letzten SHA-2-Block festschreiben; die Mitteilung wurde in mehreren Foren weitergereicht, weil sie ursprünglich auf X stand. Bemerkenswert ist die Wortwahl: Dashjr nannte den Vorgang eine mainnet rehearsal, also eine Generalprobe im Echtbetrieb. Wer schon einmal eine Generalprobe erlebt hat, bei der anschliessend niemand mehr zurückkonnte, weiss, wie viel Trost in dem Wort steckt.

Der Wechsel selbst erfolgte dann am 30. August um 06:14 UTC bei Block 961.640. Der letzte mit SHA-256d gefundene Block der Abspaltung trägt die Nummer 961.639 und stammt vom 28. August, 17:14 UTC — das lässt sich an einem öffentlichen Explorer nachsehen, der eine Bitcoin-Knots-Node ohne den neuen Algorithmus betreibt und deshalb bis heute genau dort stehen bleibt.

Acht Blöcke in drei Wochen: warum die Kette den Wechsel brauchte

Der Grund für die Eile steckt in der Difficulty. Als sich die Kette am 8. August bei Block 961.632 abspaltete, erbte sie den Schwierigkeitsgrad des Hauptnetzes von rund 127,5 Billionen — aber nur einen Bruchteil der Rechenleistung. Wie diese Anpassung funktioniert und warum sie nur alle 2.016 Blöcke greift, steht in unserem Grundlagenbeitrag Was ist die Mining Difficulty.

Die Zahlen des Explorers zeigen, was das praktisch bedeutet. Zwischen den Blöcken 961.633 und 961.639 lagen Abstände von 13.759 bis 475.772 Sekunden, also von knapp vier Stunden bis zu fünfeinhalb Tagen. Acht Blöcke in drei Wochen. Bis zur nächsten Anpassung bei Höhe 963.648 fehlten zum Zeitpunkt des Wechsels noch 2.009 Blöcke. Selbst mit der gesamten Hashrate des Bitcoin-Netzwerks wären das knapp vierzehn Tage gewesen — mit dem, was die Abspaltung tatsächlich hatte, Jahrzehnte.

Ein Proof-of-Work-Wechsel löst dieses Problem in einem Zug, weil er die Difficulty neu setzen darf. Genau das ist passiert.

Vom Stillstand in den Minutentakt

Die Wirkung war sofort sichtbar. Die Betreiber von blake2bminer.com, einer Informationsseite für Miner der neuen Kette, dokumentieren für den 30. August, 18:55 UTC, den Stand Block 961.877. Das sind 237 Blöcke in gut zwölf Stunden, also im Schnitt einer alle drei Minuten. Aus acht Blöcken in drei Wochen wurden 237 an einem halben Tag.

Das ist der Erfolg, den die Befürworter sich versprochen haben, und er ist real. Er hat nur einen Preis, den keine Difficulty-Anpassung wieder hereinholt: Die sechzehn Jahre aufgehäufte SHA-256-Arbeit, die eine Umschreibung der Bitcoin-Historie unbezahlbar macht, gelten auf der neuen Kette nicht mehr. Wer eine BLAKE2b-Kette angreifen will, muss nur mehr BLAKE2b-Leistung aufbringen als die paar Betreiber, die derzeit darauf rechnen. Der Unterschied zwischen einer Änderung, die alte Regeln verschärft, und einer, die eine neue Kette aufmacht, ist übrigens genau der zwischen Hardfork und Softfork — und diesmal ist es unmissverständlich ein Hardfork.

Was im neuen Block-Header steckt

Die technische Grundlage ist Pull Request 359 im Bitcoin-Knots-Repository, eröffnet von Dashjr am 15. August, 21 Commits. Er ersetzt nicht nur die Hashfunktion, sondern führt einen Block-Header in Version 2 ein. Die dort genannten Ziele sind:

• deutlich mehr Nonce-Raum, aufgeteilt in 128 Bit auf ASIC-Ebene, weitere 128 Bit je Maschine und 8 Bit darüber hinaus
• ein optionaler Schutz gegen Block-Withholding-Angriffe über einen XOR-Schlüssel
• vorbereitete Haken für Merged Mining, also für Seitenketten
• eine Festlegung der Transaktionszahl im Header, beschrieben als saubere Behebung von CVE-2017-12842
• Vorbereitung auf einen 64 Bit breiten Zeitstempel

Dazu kommen befristete Regeln. Die Projektseite der Kette nennt eine Obergrenze von 800.000 Gewichtseinheiten je Block — grob 300 Kilobyte — die bis zum 1. September 2027, 00:00 UTC gilt und danach automatisch entfällt. Das ist die Fortsetzung des ursprünglichen Streits mit anderen Mitteln: Es geht den Betreibern der Kette weiterhin darum, beliebige Daten aus der Kette herauszuhalten. Wer den Hintergrund dazu braucht, findet ihn bei uns unter Bitcoin Knots vs. Bitcoin Core.

Replay-Schutz gibt es nur, wenn ihr ihn anfordert

Der Punkt, der Nutzer am unmittelbarsten betrifft, steht in derselben FAQ: Die privaten Schlüssel bleiben auf beiden Ketten dieselben, und ein Replay-Schutz existiert nur als Option. Wer ihn will, muss das Signaturformat SIGHASH_UNIFIED verwenden. Ohne das kann eine Transaktion, die ihr auf einer Kette sendet, auf der anderen gültig sein.

Für den Umgang damit gilt unverändert, was der Node-Anbieter Start9 schon Mitte August zusammengetragen hat: Offene Lightning-Kanäle existieren nach einer Spaltung auf beiden Ketten, eure Node beobachtet aber nur eine davon. Und die alte Regel bleibt die wichtigste: Gebt eure Seed-Phrase niemals in ein Werkzeug ein, das euch Fork-Coins verspricht. Das war schon bei jedem früheren Fork der schnellste Weg, echte Bitcoin zu verlieren.

Mining für alle? Die Rechnung geht am ersten Tag nicht auf

In der Berichterstattung wurde BLAKE2b durchgehend als Rückkehr zum Mining mit gewöhnlicher Hardware verkauft: endlich wieder CPU und Grafikkarte statt Spezialchips. Das hält keinen Tag stand, und zwar nicht wegen einer Prognose, sondern wegen vorhandener Hardware. BLAKE2b ist der Algorithmus, mit dem seit Jahren Siacoin gemint wird, und es gibt dafür ASICs zu kaufen.

Die Miner-Seite zur neuen Kette beziffert eine RTX 3090 auf rund 5 GH/s und stellt daneben, dass eine Goldshell-SC-Box das Hundertfache schafft. CPUs bezeichnet sie als "not viable from the start". Die Projekt-FAQ selbst schreibt, ein Antminer A3 funktioniere "ab dem ersten Block". Die Kette hat also nicht die ASICs abgeschafft, sondern nur den Hersteller gewechselt — von den grossen SHA-256-Farmen zu einem Lager gebrauchter Siacoin-Geräte, das seit Jahren auf einen zweiten Frühling wartet. Das ist eine Dezentralisierung, die vor allem den Besitzern alter Hardware nützt.

Für alle, die weiterhin auf der Hauptkette minen, ändert das nichts. Der Bitaxe zeigt weiter auf den Pool eurer Wahl, bei uns auf stratum+tcp://blitzpool.yourdevice.ch:3333; die Übersicht dazu steht in der kleinen Bitcoin Solo Mining Bibel. Auf der BLAKE2b-Kette sind bislang eine Handvoll kleiner Pools aktiv, unter anderem SilentWave, PyBLOCK, Helios, PythonPool und TrueNorth — Namen, die vor drei Wochen niemand kannte.

Der Code, auf dem das läuft, ist offiziell noch ein Entwurf

Pull Request 359 trägt zum Zeitpunkt dieses Artikels weiterhin den Status Draft. In der Diskussion stehen drei von Prüfern gemeldete Befunde: Das Argument -powchangetime nimmt das dokumentierte Format time[:algo] nicht an, eine Assertion prüft 0x40 + 88 statt der offenbar richtigen 90, und die Testfunktion powhash bildet die tatsächliche Header-Konstruktion nicht ab. Die Kette läuft derweil auf einem Release-Kandidaten; die finale Fassung war für den 1. September angekündigt.

Das ist auch dann bemerkenswert, wenn ihr dem Vorhaben wohlwollend gegenübersteht. Ein Konsensbruch, der sich nicht rückgängig machen lässt, wurde hier ausgeliefert, bevor der zugehörige Vorschlag aus dem Entwurfsstadium heraus war.

Am Tag vor dem Fork verliess Luke Dashjr Ocean

Am 29. August, demselben Tag wie die Warnung an die Miner, veröffentlichten der Mining-Pool Ocean und Dashjr eine gemeinsame Mitteilung. Darin heisst es, er scheide im gegenseitigen Einvernehmen aus und lege die Ämter als Chairman, Chief Technology Officer und Verwaltungsrat nieder; das Unternehmen habe sämtliche Anteile zurückgekauft. Als Grund nennt die Mitteilung "the parties' different visions for the future of Bitcoin mining following the recent protocol developments". Dashjr startet demnach ein neues Vorhaben namens CONVOY.

Wer hier wen verlassen hat, sagt die Mitteilung nicht, und wir schreiben es deshalb auch nicht. Was sie sagt, reicht: Der Pool, der am 8. August den ersten signalisierenden Block gefunden hat, geht den Weg zur neuen Kette nicht mit — und der Rückkauf sämtlicher Anteile ist keine Formulierung für einen freundlichen Abschied.

Was in der Fachpresse steht und in den Quellen nicht

Zwei Angaben kursieren, die sich in den Primärquellen nicht wiederfinden. Erstens wird BLAKE2b mehrfach als quantenresistent beschrieben. In der Liste der Vorteile im Pull Request steht dieses Wort nicht, und die Projektseite begründet den Wechsel ebenfalls anders. Zweitens werden Zahlen zu hängenden Transaktionen und zur nötigen Hashrate genannt, die auf Testnetz-Beobachtungen einzelner Fachmedien zurückgehen; überprüfbar sind sie derzeit nicht. Beides ist im Auge zu behalten, keines davon taugt als Beleg.

Wie es weitergeht

Drei Termine bestimmen die nächsten Monate.

• 1. September 2026: Für diesen Tag ist die finale Fassung von Bitcoin Knots 29.4.1 angekündigt. Bis dahin läuft die Kette auf einem Release-Kandidaten, und Dashjr hatte einen Rücksetzer auf Block 961.639 in Aussicht gestellt, falls Fehler auftreten.
• Die erste Difficulty-Anpassung der neuen Kette: Sie zeigt, ob die Rechenleistung bleibt oder ob es sich um einen Startschub gehandelt hat. Bei dreiminütigen Blockabständen fällt sie in wenigen Tagen an — der eigentliche Belastungstest.
• 1. September 2027: An diesem Tag laufen die befristeten Datenlimits aus. Ob die Kette dann noch existiert, ist die interessantere Frage.

Offen bleibt zudem, ob eine Börse, ein Wallet-Anbieter oder ein Lightning-Dienst die Kette unterstützt. Bis heute hat sich keiner öffentlich dazu bekannt, und ohne das gibt es für die Coins auf der Abspaltung schlicht keinen Preis.

Fazit: Ein neuer Algorithmus ist keine wiederhergestellte Sicherheit

Der Wechsel hat getan, was er tun sollte. Die Kette produziert wieder Blöcke, die Difficulty-Falle ist aufgelöst, und das Vorhaben ist damit weiter, als es die meisten — uns eingeschlossen — Mitte August erwartet hätten. Wer daraus aber ableitet, das Projekt habe seine Probleme gelöst, verwechselt Blockproduktion mit Sicherheit.

Eine Kette ist so schwer angreifbar wie die Arbeit, die in ihr steckt. Diese Arbeit wurde am Sonntag auf null gesetzt und wird seither von einer Handvoll Betreiber mit gebrauchten Siacoin-ASICs neu aufgebaut. Der Code dazu ist ein Entwurf, der Replay-Schutz optional, der prominenteste Pool ausgestiegen und der Initiator gerade dabei, eine neue Firma zu gründen. Das mag alles noch werden. Aber es ist das Gegenteil dessen, was Proof of Work zum belastbaren Konsensmechanismus macht: aufgewendete Rechenleistung, die so teuer ist, dass ein Angriff sich nicht lohnt. Genau diesen Vorsprung hat die Kette am 30. August freiwillig aufgegeben. Unsere Einschätzung vom 2. Juli bleibt damit unverändert stehen.

Quellen und weiterführende Links

• bitcoinknots/bitcoin, Pull Request 359: Hardfork: New BLAKE2b proof-of-work algorithm
• btc-blake2b.org, FAQ der BLAKE2b-Kette — Datenlimits, SIGHASH_UNIFIED, Hardware
• btc-blake2b.org, Startseite des Projekts
• 110explorer.com — Explorer über eine Bitcoin-Knots-RDTS-Node, Blockabstände und Difficulty
• blake2bminer.com — Miner-Informationsseite mit Aktivierungszeitpunkt, Blockstand und Hardwarezahlen
• Joint Statement of OCEAN and Luke Dashjr, 29.08.2026
• Start9: Navigating the BIP-110 (RDTS) Activation — Replay- und Lightning-Risiken
• Weitergeleitete PSA von Luke Dashjr, 29.08.2026
• bip110.run — Chronik der Kettenspaltung vom 8. August

The post BLAKE2b-Hard-Fork ist aktiv: was jetzt wirklich läuft appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorweg das Wichtigste für alle, die uns deswegen schreiben wollen: Es liegt nicht an eurem Telefon, nicht an GrapheneOS und nicht an einer kaputten Installation. Neu aufsetzen hilft nicht.

Aurora Store meldet „Server busy": was bislang belegt ist

Der Sammelthread im Kuketz-Forum wurde am 29. August 2026 um 06:21 Uhr eröffnet und läuft seither weiter. Rund ein Dutzend Nutzer melden dieselbe Fehlermeldung, zwei melden ausdrücklich, dass bei ihnen alles funktioniert. Am Sonntagnachmittag stand dort noch immer keine Lösung, nur die Hoffnung, dass es sich von selbst erledigt. Im Bugtracker des Projekts liegt parallel das Issue 802, in dem Aurora in einer Endlosschleife bei „requesting new session" hängen bleibt — auch mit anonymem Konto.

Was im Forum an Ursachen kursiert — eine gezielte Sperre durch Google, eine VPN-Blockade, ein Fehler in der App, überlastete Dispenser —, ist Spekulation. Belegt ist keine davon. Google hat sich nicht geäussert, das Aurora-Projekt ebenfalls nicht. Wir schreiben das hier ausdrücklich hin, statt uns eine Schlagzeile zu bauen: Dass Google gerade aktiv gegen Aurora vorgeht, ist plausibel, aber unbewiesen. Was sich dagegen sehr wohl belegen lässt, ist der Grund, warum ein solcher Ausfall überhaupt alle auf einmal treffen kann.

Warum ein paar hundert Konten für Millionen Nutzer reichen müssen

Aurora ist kein eigener App-Store. Es ist, in den Worten des Projekts, „an unofficial FOSS client to Google Play" — eine andere Oberfläche vor demselben Laden. Die Apps kommen von Googles Servern, und um dort etwas anzufragen, braucht es ein Google-Konto.

Genau dafür gibt es die anonyme Anmeldung, und die funktioniert über sogenannte Token-Dispenser. Das Wiki des Projekts beschreibt sie selbst so:

„A token dispenser is a web client, that has around 250 real google accounts (inclusive of all servers), it distributes the AuthToken to anyone how makes a request to it in a defined format."

Rund 250 echte Google-Konten über alle Server hinweg. Für die gesamte Nutzerschaft. Und dasselbe Wiki nennt auch die beiden Grenzen, die Google dabei zieht: „Google enforces a limit of approximately 12 concurrent active login sessions" pro Konto, und darüber hinaus gilt eine Rate-Limit-Politik — wird die Schnittstelle zu intensiv genutzt, macht Google den Anmeldetoken schlicht ungültig.

Damit ist die Rechnung eigentlich schon aufgemacht. Wenn ein paar hundert geteilte Konten mit je etwa einem Dutzend gleichzeitiger Sitzungen den Zugang für alle tragen sollen, dann genügt eine Welle gleichzeitiger Anfragen, ein Ausfall einzelner Dispenser oder eine Handvoll gesperrter Poolkonten — und es steht für alle still. Es braucht dafür keinen Beschluss in Mountain View. Es genügt, dass niemand dort ein Interesse daran hat, dass es weiterläuft.

Anonym heisst nicht googlefrei

Der Punkt, der in dieser Woche untergeht und der uns wichtiger ist als der Ausfall selbst: Wer Aurora benutzt, redet mit Google. Nicht mit einem Konto, das euren Namen trägt — aber sehr wohl mit Googles Servern, von eurer IP-Adresse aus, mit einem Geräteprofil und einer konkreten Anfrage nach einer konkreten App. Aurora nimmt Google euer Konto weg, nicht eure Daten. Das steht ausführlicher in unserer Anleitung zum Aurora Store, und es ist der Grund, warum ein Ausfall wie dieser überhaupt möglich ist: Ihr hängt an einer fremden Infrastruktur, die euch nichts schuldet.

Der übliche Ausweg, ein eigenes Google-Konto in Aurora zu hinterlegen, funktioniert weiterhin — und ist derzeit die einzige Methode, die zuverlässig läuft. Nur ist auch der Ausweg schmaler geworden: Ein frisches Konto anzulegen, ohne eine Telefonnummer zu hinterlegen, gelingt inzwischen kaum noch. Im Forum berichtet ein Nutzer, dass er dafür eine Prepaid-Karte gekauft hat. Wer diesen Weg geht, nimmt also eine zweite Kennung in Kauf, um eine erste zu vermeiden.

Worauf ihr achten solltet

Setzt nichts neu auf. Der Fehler liegt nicht auf eurem Gerät. Ein neu geflashtes GrapheneOS ändert daran nichts und kostet euch nur einen Nachmittag.

Der günstigste Versuch zuerst. In den Aurora-Einstellungen unter „Netzwerk" den Dispenser entfernen und eine neue Sitzung anfordern hat bei einem Teil der Betroffenen geholfen. Läuft ein VPN, testweise abschalten — und Cloudflare nicht blockieren, die Dispenser laufen alle darüber. Danach hilft nur abwarten.

Wenn danach Aurora spinnt und man sich nicht mehr anmelden kann, hier der originale Dispenser von Aurora:

https://auroraoss.com/api/auth

Nehmt nicht euer Hauptkonto. Wer Aurora mit einem eigenen Google-Konto anmeldet, verknüpft jede Installation dauerhaft damit. Wenn schon, dann ein Konto, das sonst nichts von euch weiss — und mit dem Wissen, dass Google damit wieder eine Kennung mehr hat. Wie das praktisch aussieht, steht in unserem älteren Beitrag zu den Methoden gegen das Aurora-Rate-Limit.

Prüft, was ihr überhaupt über Aurora bezieht. Freie Apps gibt es über F-Droid, Apps mit GitHub-Releases über Obtainium — beide ohne jeden Google-Kontakt. Für viele bleibt am Ende eine Handvoll proprietärer Apps übrig, die es nur bei Google gibt. Genau diese Handvoll ist der Hebel, und es lohnt sich, sie einmal bewusst anzusehen.

Rechnet mit Wiederholungen. Am 30. September greift die Entwickler-Verifizierung in den ersten vier Ländern. Was Google an der Verteilung von Apps festzurrt, trifft Aurora als unautorisierten Client zuerst.

Fazit: Aurora war nie eine Unabhängigkeit, sondern eine Duldung

Ob Google diesmal aktiv eingegriffen hat, wissen wir nicht, und wir behaupten es auch nicht. Der Ausfall zeigt aber etwas, das unabhängig von der Ursache stimmt: Aurora verschafft euch keine Unabhängigkeit von Google, sondern einen bequemeren Umgang damit. Die Infrastruktur dahinter sind ein paar hundert geteilte Konten auf fremden Servern, und sie funktioniert genau so lange, wie Google sie nicht abstellt.

Das ist kein Argument gegen Aurora — die Alternative wäre der offizielle Play Store mit eurem echten Konto, und die ist schlechter. Es ist ein Argument dafür, den eigenen Bedarf an Google-Apps ehrlich zu prüfen, solange es noch freiwillig geschieht. Wer an drei Apps hängt, hat ein Problem an drei Stellen. Wer an keiner hängt, liest solche Meldungen entspannt.

Quellen und weiterführende Links

• AuroraOSS Wiki, Anonymous Logins — Token-Dispenser mit rund 250 Konten, Grenze von etwa zwölf gleichzeitigen Sitzungen, Rate-Limit-Politik von Google
• Kuketz-Forum, „Aurora Store: Server busy?" — Sammelthread seit dem 29.08.2026, Stand der Betroffenheit und der Versuche
• GitLab-Issue 802 — Endlosschleife bei „requesting new session", auch mit anonymem Konto
• Aurora Store auf GitLab — Projektseite, Selbstbeschreibung als inoffizieller Play-Client

The post Aurora Store meldet Server busy: was dahintersteckt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Harmloser, weil euch niemand etwas verbietet. Der Text adressiert Bankkunden mit keiner Silbe. Unangenehmer, weil das Ergebnis trotzdem dasselbe sein dürfte: Wer in der EU wohnt und ein Konto bei einer Bank ausserhalb des Europäischen Wirtschaftsraums hat, hat gute Aussichten, in den nächsten Monaten Post zu bekommen. Nicht aus Brüssel. Von seiner Bank.

Das ist dasselbe Muster wie vor einer Woche, nur spiegelverkehrt. Beim Digital Markets Act kostet das Fehlen einer Regel Schweizer Nutzer eine Wahl, weil Google freiwillig nichts mehr hergibt. Hier kostet das Vorhandensein einer Regel EU-Nutzer eine Wahl, weil Banken vorsorglich abwinken. Beide Male verschwindet eine Option, ohne dass jemand sie verboten hätte. Und beide Male lohnt es sich, genau hinzusehen, wer die Entscheidung eigentlich trifft — denn davon hängt ab, was ihr dagegen ausrichten könnt.

CRD VI und das Auslandskonto: was Artikel 21c wirklich regelt

CRD VI ist die sechste Fassung der europäischen Eigenkapitalrichtlinie für Banken. Sie ändert die bestehende Richtlinie 2013/36/EU und schiebt dort einen neuen Artikel 21c ein. Der Artikelwortlaut selbst lässt sich über EUR-Lex leider nicht bequem abrufen — die Datenbank liefert bei Rechtsakten dieser Grösse nur die Erwägungsgründe aus. Die sind für unsere Zwecke aber sogar besser, weil sie den Zweck in ganzen Sätzen benennen. Erwägungsgrund 5 lautet:

„Die Erbringung der in Anhang I Nummern 1, 2 und 6 der Richtlinie 2013/36/EU aufgeführten Kernbankdienstleistungen sollte von einer ausdrücklichen und harmonisierten Zulassungsanforderung im Unionsrecht abhängig gemacht werden, die besagt, dass in einem Drittland niedergelassene Unternehmen, die solche Kernbankdienstleistungen in der Union erbringen wollen, zumindest eine Zweigstelle in einem Mitgliedstaat errichten sollten und dass eine solche Zweigstelle nach dem Unionsrecht zugelassen sein muss, es sei denn, das Unternehmen beabsichtigt, Bankdienstleistungen in der Union über ein Tochterunternehmen zu erbringen."

Drei Dinge stehen da, und alle drei sind wichtig. Erstens: Adressat ist das „in einem Drittland niedergelassene Unternehmen", also die Bank. Zweitens: Es geht um Kernbankdienstleistungen, nicht um alles, was eine Bank tut. Gemeint sind die Nummern 1, 2 und 6 des Anhangs I — die Entgegennahme von Einlagen und anderen rückzahlbaren Geldern, die Kreditvergabe sowie Garantien und Zusagen. Drittens: Wer das in der EU anbieten will, braucht dort eine zugelassene Zweigstelle oder ein Tochterunternehmen.

„Drittstaat" heisst in diesem Zusammenhang schlicht: ausserhalb des Europäischen Wirtschaftsraums. Damit sind die USA gemeint, Grossbritannien, Singapur — und die Schweiz. Ein Institut in Zürich, Genf oder Zug ist gegenüber einem Kunden mit Wohnsitz in München oder Wien ein Drittstaatsinstitut im Sinne von Artikel 21c. Das ist der Grund, warum dieses europäische Gesetzgebungsverfahren auf einem Schweizer Blog steht.

Die Termine: 10. Januar 2026, 11. Juli 2026, 11. Januar 2027

Die Richtlinie musste bis zum 10. Januar 2026 in nationales Recht umgesetzt sein. Deutschland hat das mit dem Bankenrichtlinienumsetzungs- und Bürokratieentlastungsgesetz vom 29. Januar 2026 getan, das die neuen §§ 53c ff. KWG eingefügt hat — dort steht der Verweis auf Anhang I Nummern 1, 2 und 6 wörtlich im Gesetzestext. Irland war deutlich später dran und hat die Umsetzung erst am 10. Juli 2026 nachgereicht. Verlängert hat das nichts: Die Fristen der Richtlinie gelten europaweit unabhängig davon, wie pünktlich ein Mitgliedstaat war.

Angewendet wird die Zweigstellenpflicht ab dem 11. Januar 2027. Und es gibt einen zweiten Stichtag, der bereits verstrichen ist: Verträge, die vor dem 11. Juli 2026 geschlossen wurden, geniessen Bestandsschutz. Das ist der Grund, warum die Diskussion seit dem Sommer laut geworden ist — die Tür für neue Verträge unter altem Recht ist bereits zu.

Die vier Türen, die trotzdem offen bleiben

Wer nur Erwägungsgrund 5 liest, kommt tatsächlich zur Panikversion. Erwägungsgrund 6 ist derjenige, den die Aufregerartikel konsequent weglassen. Er beginnt mit einem Satz, der die ganze Zuspitzung erledigt:

„Die Inanspruchnahme von Bankdienstleistungen ausserhalb der Union, wie im Rahmen der Vereinbarung der Welthandelsorganisation über Verpflichtungen bei Finanzdienstleistungen, bleibt unberührt."

Übersetzt: Ihr dürft weiterhin ein Konto im Ausland haben. Was reguliert wird, ist nicht euer Zugriff nach draussen, sondern das aktive Angebot von draussen nach drinnen. Der Unterschied klingt nach Haarspalterei, ist aber der ganze Artikel — und er entscheidet darüber, ob ihr im Streitfall eine Rechtsposition habt oder keine.

Erste Tür: die Eigeninitiative des Kunden

Derselbe Erwägungsgrund nimmt Fälle aus, in denen sich „ein Kunde oder eine Gegenpartei ausschliesslich auf eigene Initiative an ein in einem Drittland niedergelassenes Unternehmen wendet, um die Erbringung von Bankdienstleistungen, einschliesslich ihrer Fortsetzung, zu erwirken". Im Fachjargon heisst das Reverse Solicitation, umgekehrte Kontaktaufnahme. Ausgenommen sind zusätzlich Bankdienstleistungen, „die eng mit den ursprünglich angefragten verbunden sind".

Zweite und dritte Tür: Interbank, Konzern und MiFID

Geschäfte zwischen Kreditinstituten und Geschäfte innerhalb einer Unternehmensgruppe fallen ebenfalls nicht unter die Zweigstellenpflicht. Und, für Privatkunden das Wichtigste: Wertpapierdienstleistungen nach Anhang I Abschnitt A der Richtlinie 2014/65/EU — kurz MiFID II — bleiben aussen vor. Das steht so ausdrücklich auch im deutschen Umsetzungsgesetz. Depotführung, Anlageberatung und Vermögensverwaltung aus Zürich für einen Kunden in Frankfurt sind damit nicht das Problem. Das reine Girokonto daneben schon.

Vierte Tür: Bestandsschutz für Altverträge

Verträge von vor dem 11. Juli 2026 bleiben geschützt. Das ist die grosszügigste der vier Türen und gleichzeitig die trügerischste, denn sie fällt zu, sobald sich am Vertrag etwas Wesentliches ändert. Die einschlägigen Kanzleianalysen nennen übereinstimmend Laufzeitverlängerungen, Erhöhungen von Kreditlinien, zusätzliche Auszahlungen und Novationen als solche wesentlichen Änderungen — Skadden und Arthur Cox etwa lesen den Punkt gleich. Eine Hypothek, die alle fünf Jahre prolongiert wird, ist damit nicht dauerhaft geschützt, sondern nur bis zur nächsten Verlängerung.

Warum die Ausnahmen dünner sind, als sie klingen

Vier Ausnahmen klingen nach viel Spielraum. In der Praxis sind sie es nicht, und zwar aus einem Grund, der im Gesetzestext gar nicht steht: Die Beweislast liegt bei der Bank. Wer sich auf die Eigeninitiative des Kunden beruft, muss belegen können, dass es tatsächlich der Kunde war, der angefangen hat — und dass ihn niemand aus dem Umfeld der Bank vorher angesprochen, beworben oder angeschrieben hat.

Wie das praktisch aussieht, beschreibt KPMG Law: dokumentierte Kundeninitiative für jeden Einzelfall, keine aktive Ansprache aus dem Drittstaat in die EU, saubere Trennung von Marketing, Vertrieb und Kundenbetreuung, dazu ein eigenes internes Regelwerk für den Umgang mit solchen Fällen. Ashurst formuliert die betriebswirtschaftliche Pointe daraus: Ein Geschäftsmodell, das allein auf umgekehrter Kontaktaufnahme aufbaut, ist nach dieser Richtlinie nicht vorgesehen. Anders gesagt — die Ausnahme ist als Ausnahme gemeint und nicht als Hintertür, und die Aufsicht wird sie auch so behandeln.

Dazu kommt ein Detail, das in der Debatte fast völlig untergeht: Eine Drittstaatszweigstelle bekommt keinen EU-Pass. Eine Zweigstelle in Frankfurt darf Kunden in Deutschland bedienen, nicht aber in Österreich, Frankreich und Italien gleich mit. Wer den europäischen Markt vollständig bedienen will, braucht entweder Zweigstellen in mehreren Mitgliedstaaten oder ein EU-Tochterunternehmen mit eigener Vollbanklizenz. Für eine Handvoll grosser Häuser ist das eine Rechenaufgabe. Für eine mittelgrosse Regionalbank mit dreihundert deutschen Kunden ist es keine.

Und die Zweigstelle ist auch kein Briefkasten. Die Europäische Bankenaufsichtsbehörde hat am 5. März 2026 den finalen Bericht zu den technischen Durchführungsstandards für die Aufsichtsmeldungen von Drittstaatszweigstellen vorgelegt: einheitliche Formate, gestufte Meldepflichten je nach Grösse und Komplexität, Daten auf Ebene der Zweigstelle und des Mutterinstituts. Erster Meldestichtag ist der 31. März 2027. Wer sich also fragt, warum eine Bank lieber kündigt als eine Zweigstelle eröffnet: Das hier ist die Antwort, in Tabellenform.

FATCA hat vorgeführt, wie das ausgeht

Der Mechanismus ist nicht neu, und es gibt einen Präzedenzfall, der auf europäischer Seite sogar amtlich dokumentiert ist. Der amerikanische Foreign Account Tax Compliance Act, kurz FATCA, hat US-Bürgern nie verboten, ein Konto in Europa zu führen. Er hat den Banken lediglich Meldepflichten auferlegt und sie für Verstösse haften lassen. Was daraus wurde, hat das Europäische Parlament in seiner Entschliessung vom 5. Juli 2018 in einem einzigen Satz zusammengefasst. Erwägung F stellt fest, dass Betroffene

„have their savings accounts frozen and are denied access to all banking services, including life insurance, pensions and mortgages, due to the reluctance of financial institutions to follow costly FATCA reporting"

Gesperrte Sparkonten, verweigerte Lebensversicherungen, verweigerte Hypotheken. Nicht wegen eines Verbots, sondern wegen der Unlust der Institute, teure Meldepflichten zu erfüllen. Erwägung E derselben Entschliessung hält zudem fest, die Kommission habe eingeräumt, FATCA und die zugehörigen zwischenstaatlichen Abkommen hätten „the unintended effect of hindering access to financial services in the EU" gehabt. Unbeabsichtigt, aber vorhersehbar.

Genau dieselbe Rechnung stellen jetzt Schweizer, britische und amerikanische Banken auf, nur mit vertauschten Rollen. Sie lautet nicht „dürfen wir noch?", sondern „lohnt es sich noch?". Und wenn ein Compliance-Abteilungsleiter zwischen einer dokumentierten Reverse-Solicitation-Akte für jeden einzelnen Kleinkunden und einem Kündigungsschreiben wählen darf, ist absehbar, wozu er raten wird. Der Fachdienst altii führt den Rückzug aus dem EU-Geschäft offen als dritte strategische Option neben Zweigstelle und Tochtergesellschaft — und hält fest, dass er beim Kunden als Kündigungsschreiben ankommt.

Was sich am 11. Januar 2027 tatsächlich ändert

Es lohnt, den Unterschied nüchtern nebeneinanderzulegen, weil beide Lager ihn übertreiben. Die Panikfraktion behauptet ein Verbot, das es nicht gibt. Die Beschwichtigungsfraktion — meist Beratungshäuser, die am Umsetzungsprojekt mitverdienen — behauptet, für Privatkunden ändere sich praktisch nichts. Beides stimmt nicht.

Was verschwindet, ist die Selbstverständlichkeit. Bis jetzt konnte eine Bank in Zürich einen deutschen Privatkunden betreuen, ohne dass jemand nach einer Zulassung gefragt hätte — in mehreren Mitgliedstaaten gab es dafür nationale Freistellungen, die genau das erlaubten. Ab dem 11. Januar 2027 ist der Vorgang begründungspflichtig, dokumentationspflichtig und aufsichtsrelevant. Das ist kein Verbot. Es ist eine Verteuerung, und Verteuerungen wirken bei kleinen Kunden zuerst.

Der EWR schrumpft nicht, nur der Raum ausserhalb

Eine Einschränkung gehört an dieser Stelle unbedingt dazu, weil sie in den Aufregerartikeln fehlt: Innerhalb des Europäischen Wirtschaftsraums ändert sich gar nichts. Ein Konto in Österreich, Luxemburg, Irland, den Niederlanden oder Liechtenstein ist von Artikel 21c nicht betroffen, weil dort keine Drittstaatsinstitute sitzen. Wer aus Diversifikationsgründen ein zweites Konto ausserhalb seines Heimatlands möchte, kann das weiterhin problemlos tun.

Was schrumpft, ist der Raum ausserhalb — und damit ausgerechnet der Teil, der als Rückversicherung gegen eine europäische Fehlentwicklung gedacht wäre. Wer ein Konto in der Schweiz hält, weil er den europäischen Institutionen nicht über den Weg traut, verliert genau die Absicherung, die er meinte. Wer eines in Luxemburg hält, verliert nichts. Das ist keine Nebenwirkung, es ist die Logik der Sache: Ein Binnenmarkt schützt seinen Rand, nicht seine Ausgänge.

Die Gegenposition — und warum sie nur zur Hälfte trägt

Das beste Argument für Artikel 21c ist kein europapolitisches, sondern ein aufsichtsrechtliches, und es ist ernst zu nehmen. Bis jetzt konnte ein Institut, das keiner europäischen Aufsicht untersteht, in Europa Einlagen einsammeln und Kredite vergeben, ohne dass irgendeine Behörde wusste, in welchem Umfang. Es gab keine einheitliche Meldung, keinen Überblick über die Risiken, und im Fall einer Schieflage keine europäische Einlagensicherung, auf die sich ein Kunde hätte berufen können. Der Kunde trug ein Risiko, das er in aller Regel nicht kannte. Dass eine Aufsichtsbehörde das nicht dauerhaft hinnehmen will, ist nachvollziehbar.

Auch das zweite Argument stimmt: Eine europäische Bank musste sich seit Jahren an Eigenkapitalvorschriften, Meldepflichten und Sanierungsplanung halten, während ein Institut aus einem Drittstaat dieselben Kunden ohne diese Kosten bedienen durfte. Das ist ein Wettbewerbsvorteil, für den es keine sachliche Begründung gibt.

Nur geht die Rechnung eben nur auf, wenn die Zweigstelle am Ende auch entsteht. Ein Aufsichtsregime, das dazu führt, dass die beaufsichtigte Tätigkeit gar nicht mehr stattfindet, hat kein Risiko beseitigt, sondern eine Wahlmöglichkeit. Die Aufsicht bekommt saubere Meldebögen über ein Geschäft, das es nicht mehr gibt. Und der Kunde, dem die Aufsicht das Risiko ersparen wollte, bekommt ein Kündigungsschreiben und die Empfehlung, sich an ein europäisches Institut zu wenden — dessen Konditionen, Datenweitergabe und Gebühren er sich nicht ausgesucht hat. Schutz, den niemand ablehnen kann, ist selten Schutz.

Der Zusammenhang mit dem digitalen Euro — und wo er aufhört

Es liegt nahe, Artikel 21c in dieselbe Reihe zu stellen wie den digitalen Euro, das geplante Vermögensregister und die europaweite Bargeldobergrenze, die wir im grossen EU-Kommentar auseinandergenommen haben. Und ein Zusammenhang besteht durchaus, aber ein anderer als der gern behauptete. Es gibt keinen Beleg dafür, dass CRD VI als Kapitalverkehrskontrolle gemeint wäre; die Richtlinie ist ein Bankenaufsichtsprojekt und liest sich auch so. Wer ihr eine verdeckte Absicht unterstellt, muss das belegen, und diesen Beleg hat bislang niemand geliefert.

Der tatsächliche Zusammenhang ist struktureller Art: Es ist derselbe Vorgang, wie er beim digitalen Euro bei der Haltegrenze auftritt. Eine Regel wird nicht deshalb gefährlich, weil sie euch etwas verbietet, sondern weil sie an einer Stelle ansetzt, an der ihr nicht sitzt. Beim digitalen Euro entscheidet eine Verordnung über die Obergrenze, nicht ihr. Bei Artikel 21c entscheidet die Risikoabwägung einer Bank über euren Zugang, nicht ihr. In beiden Fällen ist die Instanz, die tatsächlich entscheidet, für euch nicht erreichbar.

Der naheliegende Kurzschluss lautet an dieser Stelle: also Bitcoin. Der ist nur zur Hälfte richtig, und die falsche Hälfte kostet Geld. Selbstverwahrtes Geld löst tatsächlich das Problem, dass ein Vermittler eure Guthaben kündigen kann — niemand kann eine Wallet schliessen, deren Schlüssel er nicht hat. Es löst aber nicht das Problem, das ein Auslandskonto löst: Miete zahlen, Gehalt empfangen, eine Lastschrift einziehen lassen, in einer zweiten Währung liquide sein. Wer Bitcoin als Ersatz für ein Girokonto verkauft, verkauft eine Bohrmaschine als Regenschirm. Als Ergänzung, die niemand kündigen kann, ist die Sache dagegen ein sehr ernsthaftes Argument — dann aber bitte mit einem Blick darauf, was KYC und Pseudo-No-KYC in der Praxis wirklich leisten.

Was das für euch heisst

Gegen eine europäische Richtlinie, deren Umsetzungsfrist im Januar 2026 abgelaufen ist, richtet ein einzelner Kontoinhaber nichts mehr aus. Eine Handlungsliste wäre hier gelogen. Was ihr stattdessen habt, ist eine Lage, die sich einordnen lässt — und ein paar Unterschiede, die im Ernstfall zählen.

Ihr seid nur mittelbar betroffen, aber ihr seid es. Der Gesetzestext richtet sich nicht an euch. Das Kündigungsschreiben, das ihr eventuell bekommt, kommt trotzdem. Es ist die Entscheidung eurer Bank, nicht die Anordnung eines Gesetzgebers — genau deshalb ist sie auch verhandelbar, während ein Verbot es nicht wäre.

Das Datum eures Vertrags entscheidet mit. Wer vor dem 11. Juli 2026 abgeschlossen hat, steht anders da als jemand, der danach abgeschlossen hat. Ob der Bestandsschutz im konkreten Fall greift und was als wesentliche Vertragsänderung gilt, ist eine Rechtsfrage — dieser Artikel ist Journalismus und keine Rechtsberatung, und wo es um eine laufende Finanzierung geht, gehört die Frage einem Anwalt vorgelegt und nicht einem Blog.

Depot und Girokonto sind rechtlich zwei verschiedene Dinge. Die MiFID-Ausnahme trägt Wertpapierdienstleistungen weiter, das reine Zahlungsverkehrskonto daneben nicht. Wer beides bei derselben Auslandsbank hat, sollte damit rechnen, dass die Bank die beiden Teile unterschiedlich behandelt.

Innerhalb des EWR bleibt alles, wie es war. Wer Streuung will und nicht Distanz zu Brüssel, hat weiterhin die volle Auswahl.

Die nächsten Termine stehen fest. Am 11. Januar 2027 greift die Zweigstellenpflicht, am 31. März 2027 ist der erste Meldestichtag der EBA-Standards. Zwischen heute und dem Januar entscheiden die Institute, ob sie bleiben oder gehen. Diese Entscheidungen werden nicht in Brüssel verkündet, sondern in Serienbriefen — es lohnt sich, Post von der Bank in dieser Zeit tatsächlich zu lesen.

Fazit: Die Option verschwindet, ohne dass jemand sie verbietet

Artikel 21c CRD VI verbietet euch kein Auslandskonto, und wer das behauptet, hat die Richtlinie nicht gelesen oder verkauft nebenbei Beratung. Erwägungsgrund 6 stellt ausdrücklich klar, dass die Inanspruchnahme von Bankdienstleistungen ausserhalb der Union unberührt bleibt. Diese Klarstellung ist keine Formalie: Solange es die Entscheidung der Bank ist und kein Verbot, habt ihr eine Position — Bestandsschutz, Eigeninitiative, MiFID-Depot, im Zweifel ein Gespräch. Bei einem echten Verbot hättet ihr nichts davon.

Und trotzdem trifft es am Ende die Nutzer. Nicht weil ein Gesetzgeber es angeordnet hätte, sondern weil eine Regel, die einen Vermittler teuer und haftbar macht, diesen Vermittler zuverlässig dazu bringt, die unrentablen Kunden abzustossen. FATCA hat das vorgeführt, das Europäische Parlament hat es 2018 protokolliert, und die Erkenntnis ist offenbar in keine Folgenabschätzung eingeflossen. Der Unterschied zwischen „verboten" und „nicht mehr angeboten" ist juristisch riesig und im Alltag gleich null.

Das ist die eigentliche Lehre, und sie geht über das Bankwesen hinaus. Wirksame Einschränkungen kommen inzwischen selten als Verbot. Sie kommen als Auflage an denjenigen, der euch bedient — als Verifizierungspflicht für App-Entwickler, als Prüfpflicht für Plattformen, als Zulassungspflicht für Banken. Der Adressat trägt das Risiko, ihr tragt die Folge, und im Gesetzestext steht euer Name nirgends. Wer nur nach Verboten sucht, wird die nächsten zehn Jahre nichts finden und trotzdem immer weniger dürfen.

Quellen und weiterführende Links

• Richtlinie (EU) 2024/1619 (CRD VI), EUR-Lex — Erwägungsgründe 5 und 6 zur Zweigstellenpflicht und den Ausnahmen
• § 53c KWG — die deutsche Umsetzung mit dem Verweis auf Anhang I Nummern 1, 2 und 6
• CMS zur deutschen Umsetzung — Bankenrichtlinienumsetzungsgesetz vom 29. Januar 2026, §§ 53c und 53cc KWG
• EBA, Pressemitteilung vom 5. März 2026 — Durchführungsstandards für die Meldungen von Drittstaatszweigstellen, erster Stichtag 31. März 2027
• Entschliessung des Europäischen Parlaments vom 5. Juli 2018 zu FATCA — Erwägungen E und F zu gesperrten Konten und verweigerten Bankdienstleistungen
• Skadden, CRD VI: What US Banks Need to Know — Stichtage, Ausnahmen, wesentliche Vertragsänderungen
• Arthur Cox zu Artikel 21c — Kerndienstleistungen und der Begriff der umgekehrten Kontaktaufnahme
• William Fry zur irischen Umsetzung — verspätete Umsetzung am 10. Juli 2026 ohne Verlängerung der Fristen
• Ashurst zu Drittstaatszweigstellen — Beweislast und Grenzen der Reverse-Solicitation-Ausnahme
• KPMG Law zu den verbleibenden Wegen — Dokumentationspflichten und Meldefrequenzen der Zweigstellenklassen
• Latham & Watkins zur Kreditvergabe an EU-Kreditnehmer — Auswirkungen der Zulassungspflicht auf Finanzierungen
• altii zum Ende der Freistellung — Folgen für Privatkunden, MiFID-Abgrenzung und die Rückzugsoption der Banken

The post CRD VI Auslandskonto: verboten wird gar nichts appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Paperless-ngx löst genau dieses Problem, und zwar auf eurer eigenen Hardware. Die Software liest jedes eingeworfene Dokument per Texterkennung ein, legt eine durchsuchbare Archivfassung daneben, rührt das Original nicht an und macht den ganzen Bestand über eine Volltextsuche zugänglich. Kein Abo, kein fremdes Rechenzentrum, kein Anbieter, der in drei Jahren den Dienst einstellt. In dieser Anleitung richtet ihr Paperless-ngx mit Docker Compose ein, von der leeren Verzeichnisstruktur bis zum ersten gefundenen Dokument — inklusive der Stellen, an denen es erfahrungsgemäss klemmt.

Was Paperless-ngx ist, bevor ihr es einrichtet

Paperless-ngx ist ein selbst gehostetes Dokumentenverwaltungssystem unter der GPL-3.0 und laut eigener Projektbeschreibung der offizielle Nachfolger von Paperless und Paperless-ng. Das Projekt beschreibt sich selbst als „community-supported“ und hat die Verantwortung bewusst auf mehrere Personen verteilt, statt an einem einzelnen Entwickler zu hängen — ein Detail, das bei selbst gehosteter Software wichtiger ist als jede Funktionsliste. Technisch steckt Django im Rückgrat und Angular in der Oberfläche, ausgeliefert wird primär als Container.

Die Texterkennung macht Paperless nicht selbst. Dafür ist OCRmyPDF zuständig, das eine Textebene unter das gescannte Bild legt, sodass die Seite aussieht wie vorher, sich aber durchsuchen und kopieren lässt. OCRmyPDF wiederum stützt sich auf Tesseract, die freie OCR-Engine unter Apache-2.0, die aus einer Entwicklung von Hewlett-Packard zwischen 1985 und 1994 hervorgegangen ist, danach jahrelang bei Google lag und heute über hundert Sprachen erkennt. Das Ergebnis ist standardmässig ein PDF/A, also das Format, das für Langzeitarchivierung gedacht ist.

Wichtig für das Vertrauen in die Sache: Paperless speichert laut Dokumentation immer das Original und überschreibt es nie. Die Archivfassung entsteht daneben. Wenn die Texterkennung Unsinn produziert, ist das ärgerlich, aber nicht endgültig.

Version 3.0 und was sie mitbringt

Die aktuelle Hauptversion ist 3.0, veröffentlicht am 22. Juli 2026, gefolgt von den Punktständen 3.0.1 bis 3.0.3 innerhalb der darauffolgenden drei Tage — nachzulesen in der Release-Übersicht. Der Eintrag zu 3.0.0 nennt einige harte Schnitte: Die Suchmaschine Whoosh ist durch Tantivy ersetzt, die API-Version 1 ist weg, Python 3.10 wird nicht mehr unterstützt, und die Dokumentverschlüsselung wurde abgeschafft. Dazu kommen ein Plugin-Rahmen für Dokumentparser und eine Versionierung für Dokumente.

Ebenfalls neu in 3.0: eine Anbindung an Sprachmodelle unter dem Namen „Paperless AI“ und die Möglichkeit, die Texterkennung per Azure AI auszulagern. Wer eine Dokumentenverwaltung aufsetzt, um seine Steuerunterlagen aus fremden Rechenzentren herauszuholen, wird für die zweite Funktion vermutlich wenig Verwendung haben. Sie ist da; sie zu ignorieren ist eine gültige Konfigurationsentscheidung.

Was Paperless-ngx nicht ist

Es ist kein Dateisynchronisierer. Es ersetzt keine Nextcloud und will es auch nicht. Und es ist ausdrücklich keine Ablage für Dateien, die ihr weiterbearbeiten wollt — was hineingeht, ist ein abgeschlossenes Dokument: Rechnung, Vertrag, Lohnabrechnung, Arztbericht. Wer versucht, seine Projektordner darin zu verwalten, kämpft gegen das Werkzeug statt mit ihm.

Voraussetzungen: Hardware, Linux, Docker

Paperless läuft auf jedem Linux-Rechner, der dauerhaft an ist: ein alter Mini-PC, ein Heimserver, eine virtuelle Maschine, ein Raspberry Pi 4 oder 5. Die Texterkennung ist der einzige Teil, der wirklich Rechenzeit frisst, und sie läuft im Hintergrund. Ein Dokument, das drei Minuten braucht statt zwanzig Sekunden, ist beim Einlesen von zehn Seiten pro Woche kein Problem. Beim Erstimport von zwölf Jahren Aktenordnern schon — plant dafür eine Nacht ein und nicht eine Kaffeepause.

Für Arbeitsspeicher gilt: unter 2 GB wird es zäh, ab 4 GB ist es entspannt. Der Speicherplatz richtet sich nach eurem Papierberg; ein einseitiger Scan in 300 dpi landet je nach Vorlage im niedrigen einstelligen Megabyte-Bereich, und Paperless legt Original und Archivfassung ab, rechnet also grob mit dem Doppelten.

Gebraucht wird Docker samt Compose-Plugin. Wer das noch nicht installiert hat, findet den Weg dorthin in unserer Anleitung Docker Basics und Installation auf Mint, Ubuntu und Debian. Es gibt daneben einen Weg ohne Container, und die Installationsdokumentation beschreibt ihn auch: Linux zwingend, Python 3.11 bis 3.14, dazu unter anderem imagemagick, ghostscript, tesseract-ocr, ein Redis-kompatibler Broker und eine Datenbank. Diese Anleitung nimmt den Container-Weg, weil dort die Abhängigkeiten bereits stimmen und ein Update aus zwei Befehlen besteht statt aus einem Nachmittag.

Die Container und Ablagen, aus denen Paperless besteht

Bevor der erste Befehl fällt, lohnt ein Blick auf den Aufbau, denn er entscheidet später darüber, was ins Backup muss. Die empfohlene Variante mit PostgreSQL besteht laut der zugehörigen Compose-Datei aus drei Diensten: webserver mit dem Abbild ghcr.io/paperless-ngx/paperless-ngx:latest auf Port 8000, db mit postgres:18 und broker mit valkey:9-alpine, dem quelloffenen Redis-Nachfolger, der die Warteschlange der Verarbeitungsaufträge hält.

Dazu kommen vier Docker-Volumes — data, media, pgdata, redisdata — und zwei Ordner, die direkt aus eurem Dateisystem eingehängt werden: ./consume als Eingangskorb und ./export für Sicherungen. Die Trennung ist der Kern der Sache: Was ihr seht und anfasst, ist der Eingangskorb. Was das Archiv ausmacht, liegt in den Volumes.

Schritt 1: Verzeichnis anlegen und die Vorlagen holen

Legt ein eigenes Verzeichnis an, in dem alles zusammenbleibt. Alle weiteren Befehle laufen darin.

mkdir -p ~/paperless && cd ~/paperless
mkdir -p consume export

Aus dem Verzeichnis docker/compose des Projekts braucht ihr drei Dateien: eine docker-compose.*.yml passend zur gewünschten Datenbank, dazu docker-compose.env und .env. Für eine Neuinstallation empfiehlt die Dokumentation PostgreSQL.

BASE=https://raw.githubusercontent.com/paperless-ngx/paperless-ngx/main/docker/compose

wget -O docker-compose.yml  $BASE/docker-compose.postgres.yml
wget -O docker-compose.env  $BASE/docker-compose.env
wget -O .env                $BASE/.env

Die Dokumentation bietet zusätzlich ein Installationsskript an, das sich per curl holen und direkt in die Shell schütten lässt. Es funktioniert und fragt die wichtigsten Werte interaktiv ab. Wer ein Skript aus dem Netz ungelesen mit den eigenen Rechten ausführt, sollte das trotzdem bewusst tun und nicht aus Bequemlichkeit — ladet es herunter, lest es, führt es dann aus. Der manuelle Weg oben braucht drei Minuten länger und ihr wisst danach, was auf eurem Rechner steht.

Schritt 2: docker-compose.env ausfüllen

Diese Datei ist die eigentliche Konfiguration. Die Vorlage enthält die wichtigsten Werte bereits auskommentiert. Vier davon setzt ihr in jedem Fall.

Die Benutzer-ID. Der Container muss in den Eingangsordner schreiben dürfen, und zwar mit derselben Kennung wie ihr. Fragt sie ab:

id -u
id -g

Der geheime Schlüssel. PAPERLESS_SECRET_KEY ist Pflicht. Die Dokumentation ist deutlich: „Paperless will refuse to start if this is not set.“ In der Vorlage steht der Platzhalter change-me, und genau so ist er gemeint. Erzeugt einen echten Wert:

python3 -c "import secrets; print(secrets.token_urlsafe(64))"

Die Zeitzone. Ohne Angabe läuft alles in UTC, was dazu führt, dass ein Dokument vom Abend das Datum des Folgetags bekommt. Für die Schweiz also Europe/Zurich.

Die OCR-Sprache. Der Vorgabewert ist eng. Ein deutscher Mietvertrag, den Tesseract für Englisch hält, ergibt eine Textebene, die zwar existiert, aber nichts findet. Setzt PAPERLESS_OCR_LANGUAGE=deu. Zusätzliche Sprachen kommen über PAPERLESS_OCR_LANGUAGES dazu; laut Vorlage bringt das Abbild Englisch, Deutsch, Italienisch, Spanisch und Französisch bereits mit, für Deutsch ist also nichts nachzuinstallieren.

USERMAP_UID=1000
USERMAP_GID=1000
PAPERLESS_SECRET_KEY=<der erzeugte Wert>
PAPERLESS_TIME_ZONE=Europe/Zurich
PAPERLESS_OCR_LANGUAGE=deu

Ein fünfter Wert wird gebraucht, sobald Paperless nicht mehr nur lokal erreichbar ist: PAPERLESS_URL. Diese Variable setzt laut Konfigurationsdokumentation gleichzeitig ALLOWED_HOSTS, CORS_ALLOWED_HOSTS und CSRF_TRUSTED_ORIGINS. Wer sie vergisst und trotzdem einen Reverse Proxy davorstellt, bekommt beim Anmelden einen CSRF-Fehler und sucht danach an der falschen Stelle.

Schritt 3: Die Ordner in der Compose-Datei prüfen

Öffnet docker-compose.yml und seht euch den Abschnitt volumes des Dienstes webserver an. Zwei Einträge sind Pfade aus eurem Dateisystem und keine Docker-Volumes:

    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - ./export:/usr/src/paperless/export
      - ./consume:/usr/src/paperless/consume

Wenn der Eingangskorb woanders liegen soll — etwa in einem Ordner, in den euer Scanner oder eure Nextcloud ablegt — ändert ihr hier den linken Teil vor dem Doppelpunkt. Der rechte Teil bleibt unangetastet, das ist der Pfad im Container. Der Port lässt sich im Abschnitt ports ebenfalls verschieben, falls 8000 schon belegt ist; geändert wird nur die Zahl links.

Achtet darauf, dass der Eingangsordner eurem Benutzer gehört. Ein Eingangskorb, in den der Container nicht hineinschauen darf, ist die häufigste Ursache für Dokumente, die einfach liegen bleiben und dabei keine Fehlermeldung produzieren.

Schritt 4: Starten und den ersten Benutzer anlegen

docker compose pull
docker compose up -d
docker compose logs -f webserver

Der erste Start dauert, weil Datenbankmigrationen laufen. Beobachtet das Protokoll, bis keine neuen Zeilen mehr kommen, und brecht die Anzeige dann mit Strg+C ab — das beendet nur die Protokollausgabe, nicht die Container.

Danach ist die Oberfläche unter http://127.0.0.1:8000 erreichbar, beziehungsweise unter der IP-Adresse des Servers. Beim ersten Aufruf lässt sich das Administratorkonto direkt im Browser anlegen. Falls das nicht erscheint oder ihr ein weiteres Konto braucht, geht es auch über die Kommandozeile; laut Verwaltungsdokumentation laufen alle Verwaltungsbefehle im laufenden Betrieb über docker compose exec webserver:

docker compose exec webserver createsuperuser

Schritt 5: Das erste Dokument einwerfen

Der Hauptweg in die Datenbank ist der Eingangsordner. Die Dokumentation nennt ihn beim Namen: „The primary method of getting documents into your database is by putting them in the consumption directory.“ Kopiert eine PDF-Datei nach ~/paperless/consume und schaut der Oberfläche zu. Nach einigen Sekunden bis Minuten erscheint das Dokument in der Übersicht, die Datei im Eingangsordner verschwindet, und im Archiv liegen zwei Fassungen: euer unverändertes Original und die durchsuchbare Archivfassung.

Daneben gibt es drei weitere Wege. Die Oberfläche hat einen Hochladeknopf und nimmt auch Dateien per Ziehen und Fallenlassen an. Paperless kann E-Mail-Konten abrufen und Anhänge automatisch verarbeiten. Und es erkennt Archivnummern per Strichcode, was beim Digitalisieren grosser Papierbestände hilft, wenn ihr die Blätter physisch behalten und später wiederfinden wollt.

Zwei Schalter aus der Konfiguration lohnen sich früh. PAPERLESS_CONSUMER_RECURSIVE steht auf false; auf true gesetzt schaut Paperless auch in Unterordner des Eingangskorbs. In Kombination mit PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS werden diese Unterordner zu Schlagwörtern — wer ohnehin nach Ordnern sortiert scannt, bekommt damit die halbe Verschlagwortung geschenkt.

Für den Nachschub gilt: Ihr braucht einen Scanner, der brauchbare Vorlagen liefert. Wie das unter Linux ohne Herstellersoftware funktioniert, steht in Scannen unter Linux und GIMP Scan Anleitung — 300 dpi sind für Dokumente der sinnvolle Wert, mehr bringt der Texterkennung nichts und kostet nur Platz.

Ordnung, die trägt: Schlagwörter, Korrespondenten, Dokumenttypen

Paperless kennt vier Ordnungsmerkmale, und sie tun nicht dasselbe. Schlagwörter gruppieren Dokumente frei; ein Dokument kann mehrere tragen. Korrespondenten sind Person, Behörde oder Firma, von der ein Dokument stammt oder an die es ging. Dokumenttypen klassifizieren die Art: Rechnung, Brief, Kontoauszug. Speicherpfade bestimmen, wo die Datei tatsächlich abgelegt wird.

Die Versuchung, hier gleich ein dreistufiges Ordnungssystem mit 60 Schlagwörtern zu bauen, ist gross. Widersteht ihr. Die Volltextsuche findet Dokumente über ihren Inhalt, und zwar über Inhalt, Titel, Korrespondent, Typ und Schlagwörter gleichzeitig. Fünf Schlagwörter, die ihr wirklich benutzt, schlagen sechzig, die ihr beim Einlesen jedes Mal neu erwägen müsst.

Die Suche versteht dabei mehr als eine Wortliste. Laut Dokumentation funktionieren logische Ausdrücke wie shopname AND (product1 OR product2), gezielte Filter wie type:invoice tag:unpaid, Datumsbereiche in der Form created:[2005 to 2009] und Platzhalter wie produ*name. Damit findet ihr die Rechnung vom Sanitär aus dem vorletzten Winter, ohne zu wissen, wie er heisst.

Office-Dateien und E-Mails: Gotenberg und Tika

Wer nicht nur Scans, sondern auch Word-, Excel- und PowerPoint-Dateien oder deren LibreOffice-Entsprechungen ablegen will, braucht zwei zusätzliche Dienste. Die Compose-Datei docker-compose.postgres-tika.yml bringt sie mit: docker.io/gotenberg/gotenberg:8.33 für die Umwandlung und docker.io/apache/tika:latest für die Inhaltsanalyse. Angebunden werden sie über drei Variablen:

      PAPERLESS_TIKA_ENABLED: 1
      PAPERLESS_TIKA_ENDPOINT: http://tika:9998
      PAPERLESS_TIKA_GOTENBERG_ENDPOINT: http://gotenberg:3000

Gotenberg übernimmt daneben die Umwandlung von .eml-Dateien, also gespeicherten E-Mails. Wer diese Variante gleich zu Beginn nimmt, spart sich den späteren Umbau; wer nur Papier verarbeitet, lässt die beiden Container weg und spart sich rund ein Gigabyte Arbeitsspeicher.

Von aussen erreichbar? Erst lesen, dann öffnen

Hier steht eine Warnung, die aus dem Projekt selbst kommt und nicht von uns: Sensible Dokumente gehören auf einen lokalen Server, und Paperless-ngx sollte nie auf einem Rechner laufen, dem ihr nicht vertraut. Das ist kein Kleingedrucktes, sondern die Zusammenfassung dessen, was in diesem Archiv liegt — Ausweiskopien, Lohnabrechnungen, Arztberichte, Verträge. Ein kompromittierter Paperless-Server ist eine vollständige Selbstauskunft.

Daraus folgt eine klare Reihenfolge. Erste Wahl ist gar kein Zugriff von aussen: Paperless bleibt im Heimnetz, und wer von unterwegs heranwill, baut vorher einen Tunnel. Wie das geht, steht in Schnell und einfach einen Wireguard VPN betreiben. Ein VPN gibt dem Angreifer nichts, was er ohne Schlüssel überhaupt ansprechen könnte.

Wenn es doch eine öffentlich erreichbare Adresse sein muss, gehört ein Reverse Proxy mit TLS davor, und PAPERLESS_URL muss auf genau diese Adresse zeigen. Den Weg dorthin ohne Certbot beschreibt Caddy Reverse Proxy einrichten: HTTPS ohne Certbot; die Struktur ist dieselbe wie bei den dort gezeigten Diensten, nur mit Port 8000 statt 2283. Und selbst dann bleibt die Empfehlung des Projekts bestehen, dass die Maschine unter eurer Kontrolle steht.

Backup: was gesichert werden muss und was nicht reicht

Ein Dokumentenarchiv ohne Sicherung ist eine sehr aufwendige Art, Papier wegzuwerfen. Paperless bietet dafür zwei Wege, und sie schliessen sich nicht aus.

Der erste ist der Exporter. Er schreibt sämtliche Daten samt Einstellungen und Datenbankinhalt in einen Ordner — unabhängig von der Installationsart und damit auch das Mittel der Wahl, wenn ihr später von SQLite auf PostgreSQL oder von Docker auf ein anderes System wechselt.

docker compose exec webserver document_exporter ../export

Der Rückweg heisst document_importer und nimmt sowohl ein Verzeichnis als auch ein ZIP-Archiv des Exporters entgegen:

docker compose exec webserver document_importer ../export

Der zweite Weg ist die Sicherung der Docker-Volumes. Relevant sind laut Dokumentation paperless_media mit den Dokumenten, paperless_data mit Hilfsdaten und gegebenenfalls der SQLite-Datenbank sowie paperless_pgdata mit der PostgreSQL-Datenbank. Wer nur media sichert, hat am Ende die Dateien, aber keine Schlagwörter, keine Korrespondenten und keinen Suchindex — also genau den Zustand, aus dem ihr Paperless aufgesetzt habt, um herauszukommen.

Der Exportordner gehört anschliessend in eure normale Sicherungskette. Was die zu leisten hat, steht in Was ist ein gutes BackUp, und wie sich das auf einem Linux-Rechner mit Borg und einem NAS umsetzen lässt, in Linux PC lokal und auf NAS sichern. Der Exporter alleine ist keine Sicherung, solange die Ausgabe auf derselben Platte liegt wie das Original.

Aktualisieren

Die Dokumentation gibt eine feste Reihenfolge vor: keine laufenden Verarbeitungen, dann Sicherung, dann anhalten, dann aktualisieren. Migrationen laufen beim Start automatisch.

docker compose down
docker compose pull
docker compose up -d

Wenn etwas nicht klappt

Der Container startet nicht und beendet sich sofort wieder. Häufigste Ursache ist ein fehlender oder unveränderter PAPERLESS_SECRET_KEY. Paperless verweigert ohne diesen Wert den Start. Prüft die Ausgabe von docker compose logs webserver, dort steht es im Klartext.

Dokumente bleiben im Eingangsordner liegen. Fast immer sind es Berechtigungen: USERMAP_UID und USERMAP_GID stimmen nicht mit dem Besitzer des Ordners überein. Vergleicht die Ausgabe von id -u mit dem Wert in docker-compose.env und prüft mit ls -ln consume, wem der Ordner gehört.

Der Eingangsordner liegt auf einer Netzwerkfreigabe. Die Überwachung von Dateiänderungen funktioniert über Netzwerkdateisysteme nicht zuverlässig. Für diesen Fall gibt es PAPERLESS_CONSUMER_POLLING; damit fragt Paperless in einem festen Takt nach, statt sich auf Ereignisse zu verlassen.

Die Texterkennung liefert Buchstabensalat. Prüft zuerst PAPERLESS_OCR_LANGUAGE. Steht dort noch eng, erkennt Tesseract deutsche Umlaute und Wortbilder schlecht. Zweite Ursache ist die Vorlage selbst: Ein schiefer, zu dunkler oder mit 150 dpi gescannter Beleg ist auch für eine gute Engine schwer.

Nach dem Anmelden erscheint ein CSRF-Fehler. Das passiert hinter einem Reverse Proxy, wenn PAPERLESS_URL nicht gesetzt ist oder nicht exakt der aufgerufenen Adresse entspricht. Die Variable setzt ALLOWED_HOSTS und CSRF_TRUSTED_ORIGINS gleich mit; sie ist der richtige Hebel, nicht die Einzelvariablen.

Nach einem Update fehlen Funktionen oder es hakt an unerwarteter Stelle. Die Release-Notizen zu 3.0 warnen ausdrücklich vor veralteten Dateien bei Aktualisierungen ohne Container. Wer den Weg ohne Docker gewählt hat, sollte die Hinweise im jeweiligen Release lesen, statt nur die Versionsnummer zu erhöhen.

Fazit: Ein Archiv, das euch gehört, schlägt eines, das nur sucht

Der Reiz von Paperless-ngx liegt nicht in der Texterkennung. Die kann jeder Cloud-Anbieter, meistens sogar besser, weil er mehr Rechenzeit hineinsteckt und sein Modell an fremden Dokumenten trainiert hat. Der Reiz liegt darin, dass am Ende ein Verzeichnis auf einer Platte in eurer Wohnung steht, in dem eure Originale unverändert liegen, daneben eine durchsuchbare Fassung in einem Archivformat, und dass ihr beides mit einem einzigen Befehl exportieren und woandershin mitnehmen könnt.

Das ist der Unterschied zwischen einem Werkzeug und einem Dienst. Ein Dienst funktioniert, solange jemand anderes will, dass er funktioniert — und die Preisliste, die Nutzungsbedingungen und die Frage, wer beim Anbieter in eure Steuerunterlagen sehen darf, ändern sich ohne euch. Ein Werkzeug funktioniert, solange ihr es pflegt. Der Aufwand dafür ist die Konfigurationsdatei oben, ein Update alle paar Wochen und eine Sicherung, die tatsächlich läuft. Das ist mehr als null, und es ist deutlich weniger als ein Abo, das ihr nicht kündigen könnt, ohne den Zugriff auf zwölf Jahre Papier zu verlieren.

Fangt klein an: ein Ordner, ein Korrespondent, fünf Schlagwörter. Der Rest kommt beim Benutzen. Der Aktenordner mit der Aufschrift „Wichtig“ darf bleiben, wo er ist — ihr müsst ihn nur nicht mehr aufmachen.

Quellen und weiterführende Links

• paperless-ngx auf GitHub — Projektbeschreibung, Lizenz GPL-3.0, Sicherheitshinweis zum Betrieb
• docs/setup.md — Installation mit Docker Compose und Voraussetzungen für den Weg ohne Container
• docs/configuration.md — sämtliche Umgebungsvariablen mit Vorgabewerten
• docs/administration.md — Exporter, Importer, Verwaltungsbefehle und Update-Reihenfolge
• docs/usage.md — Eingangsordner, Schlagwörter, Korrespondenten, Suchsyntax
• docker-compose.postgres.yml — die drei Dienste, ihre Abbilder und die Volumes
• docker-compose.postgres-tika.yml — Gotenberg und Tika für Office-Dateien und E-Mails
• docker-compose.env — die Vorlage mit Benutzer-ID, Schlüssel, Zeitzone und OCR-Sprachen
• Release-Übersicht und Release-Notizen zu 3.0.0
• OCRmyPDF — die Textebene unter dem Scan, PDF/A als Vorgabe, Lizenz MPL-2.0
• Tesseract — die OCR-Engine dahinter, Apache-2.0, über hundert Sprachen
• Eigene Anleitungen: Docker Basics, Caddy Reverse Proxy, Wireguard VPN, Scannen unter Linux, Was ist ein gutes BackUp, Linux PC lokal und auf NAS sichern

The post Paperless-ngx einrichten: papierlos ohne Cloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Stiftung wird für drei Jahre exklusiver Sponsor von Hyprland, jenem Wayland-Compositor, auf dem Omarchy aufbaut. Damit hängt ein sichtbares Stück des freien Linux-Desktops an einer einzigen Geldquelle – und über deren Regeln ist bisher nichts veröffentlicht.

Was Omarchy ist, in drei Sätzen

Linux ist kein einzelnes Produkt, sondern ein Baukasten. Der Kern ist überall derselbe, aber drumherum stellt jedes Projekt seine eigene Auswahl an Programmen und seine eigene Bedienoberfläche zusammen. Solche fertigen Zusammenstellungen heissen Distributionen. Ubuntu und Linux Mint sind die bekanntesten, Arch Linux ist eine weitere — und alle im Vergleich stehen in unserer Übersicht der Linux-Betriebssysteme.

Arch gilt unter diesen Zusammenstellungen als das Rohmaterial. Nach der Installation steht ihr vor einem schwarzen Bildschirm mit einer Eingabezeile, alles Weitere baut ihr selbst zusammen. Das kostet Tage und schreckt die meisten ab. Genau diese Arbeit nimmt Omarchy ab: Es setzt auf Arch auf und liefert ein fertig eingerichtetes System, mit Browser, Texteditor, Terminal, Büropaket und einem durchgehenden Farbschema, alles schon aufeinander abgestimmt. Das Projekt nennt sich selbst eine omakase-Distribution, nach dem japanischen Menü, bei dem der Koch entscheidet, was auf den Teller kommt. Ihr sucht nichts aus, ihr bekommt ein durchkomponiertes Ganzes.

Die Bedienoberfläche dazu heisst Hyprland. Sie stapelt Fenster nicht frei übereinander, wie ihr das von Windows kennt, sondern teilt den Bildschirm automatisch auf: Öffnet ihr ein zweites Programm, rückt das erste zur Seite, und beide liegen nebeneinander. Wer schon einmal zwei Fenster mit der Maus mühsam nebeneinandergezogen hat, bekommt hier die Variante, die das von allein erledigt — gesteuert wird vor allem über die Tastatur. Was die Begriffe im Einzelnen bedeuten, steht in unserer Begriffsübersicht zu Linux.

Hinter dem Projekt steht David Heinemeier Hansson, in der Entwicklerwelt als DHH bekannt, Erfinder von Ruby on Rails und Mitgründer von 37signals. Der Quellcode liegt unter der MIT-Lizenz auf GitHub, im Konto der Firma Basecamp, und hat dort rund 23'700 Sterne gesammelt.

Acht Namen, acht Millionen Dollar

Die Ankündigung der Stiftung nennt die Geldgeber offen. Je eine Million Dollar kommen von Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell (Dell Technologies), Jack Dorsey (Block), Matthew Prince (Cloudflare), Brendan Iribe (Mitgründer von Oculus), Jason Fried (37signals) und von Hansson selbst.

Was die Stiftung tun soll, steht in einem einzigen Satz der Ankündigung: Sie werde «die Marken halten, die Infrastruktur finanzieren, die Arbeit bewerben und die Open-Source-Projekte und Entwickler unterstützen, von denen Omarchy abhängt». Das Ziel formuliert Hansson im selben Text deutlich grösser, nämlich die Art zu verändern, wie Menschen zu ihren Computern stehen. Wer schon länger dabei ist, kennt den Satz vom Jahr des Linux-Desktops. Für alle, die den Umstieg tatsächlich planen, ist unser Leitfaden für den Wechsel von Windows auf Linux der nüchternere Einstieg.

Der zweite Teil der Meldung: Hyprland bekommt einen exklusiven Sponsor

Die interessantere Ankündigung ist die zweite. Omacom wird laut eigener Mitteilung ab dem 10. Oktober 2026 für drei Jahre exklusiver Sponsor von Hyprland, mit einer Option auf zwei weitere Jahre. Hyprland ist kein Beiwerk von Omarchy, sondern dessen Oberfläche: der Compositor, der unter Wayland die Fenster verwaltet, zeichnet und anordnet. Fällt er aus, ist Omarchy ein Terminal.

Für Vaxry, den Hauptentwickler von Hyprland, ist das eine gute Nachricht, und das soll hier nicht kleingeredet werden. Er kann laut der Mitteilung künftig an Hyprland arbeiten, ohne sich um kommerzielle Verwertung oder Spendenaufrufe kümmern zu müssen. Sichtbare Folge: Hyprperks, das kostenpflichtige Unterstützerprogramm des Projekts, wird für alle kostenlos. Das Programm war im Juli 2025 gestartet und kostete nach Angaben des Fachmediums Linuxiac fünf Euro im Monat; Mitglieder bekamen dafür Zugang zu einem eigenen Forum und vorkonfigurierte Setups. Persönliche Spenden nimmt das Projekt weiterhin an.

Was «exklusiv» bedeutet, sagt niemand

Hier fängt das Problem an. Die Mitteilung nennt drei bisherige Unterstützer von Hyprland – 37signals, Butterfly und Framework – und stellt Omacom als exklusiven Sponsor daneben. Was das Wort in diesem Vertrag heisst, steht nirgends. Es kann bedeuten, dass Omacom als einziger Sponsor genannt werden will. Es kann bedeuten, dass Hyprland keine anderen Firmensponsoren mehr annehmen darf. Die beiden Lesarten sind für die Unabhängigkeit eines Projekts sehr verschieden weit voneinander entfernt.

Ebenso wenig veröffentlicht ist die Summe. Acht Millionen Dollar sind der Gesamtbetrag der Stiftung, nicht der Betrag, der an Hyprland fliesst. Wie viel es ist, über welchen Auszahlungsplan, unter welchen Bedingungen und was passiert, wenn die Stiftung nach drei Jahren nicht verlängert – all das steht in keiner der beiden Ankündigungen. Ein Projekt, das seinen Hauptentwickler aus einer einzigen Quelle bezahlt, sollte diese Frage beantworten können, bevor sie jemand stellt.

Auf der Seite von Hyprland selbst war zum Zeitpunkt dieses Artikels keine eigene Stellungnahme abrufbar. Die Ankündigung steht bisher nur auf der Seite dessen, der zahlt.

Die Marken gehen an die Stiftung, der Code bleibt bei 37signals

Eine Stiftung wird üblicherweise gegründet, um ein Projekt aus der Verfügungsgewalt einer Firma zu lösen. Bei Omarchy ist bisher nur der kleinere Teil gewandert. Die Marken hält künftig Omacom. Das Repository liegt weiterhin unter github.com/basecamp/omarchy, also im Konto der Firma, deren Mitgründer Hansson ist und deren Chef Jason Fried zu den Geldgebern gehört. Auch das Handbuch ist inzwischen auf eine omacom-Adresse umgezogen, der Code aber nicht.

Dazu fehlt bislang das, was eine Stiftung erst zu einer Stiftung macht: Rechtsform, Sitz, Statuten, Organe, Aufnahme neuer Geldgeber, Regeln für Interessenkonflikte. Nichts davon ist veröffentlicht. Solange das so bleibt, ist «Foundation» ein Wort auf einer Webseite und keine Struktur, an der sich jemand festhalten kann.

Ein Geldgeber sitzt im Kernteam

Zwei Tage vor der Stiftungsmeldung, am 19. August 2026, hat Omarchy sein Kernteam vorgestellt: Ryan Hughes, Tobi Lütke, Bjarne Øverli, HANCORE und Spencer Bull. Dieses Team soll, so die Mitteilung, gemeinsam die Richtung der Distribution bestimmen.

Tobi Lütke steht damit auf beiden Listen. Er ist einer der acht Geldgeber und zugleich eines von fünf Mitgliedern des Gremiums, das über die Richtung entscheidet. Das ist kein Vorwurf an eine Person – in kleinen Projekten sind solche Doppelrollen normal, und Lütke trägt seit längerem Code bei. Es ist ein Hinweis darauf, wie klein der Kreis ist. Bei einer Distribution mit veröffentlichter Governance wäre diese Konstellation eine Zeile in einem Reglement. Hier ist sie eine Beobachtung ohne Regelwerk dahinter.

Der Einwand, der berechtigt ist

Gegen all das lässt sich mit einigem Recht einwenden: Freie Software krankt seit Jahrzehnten daran, dass niemand die Leute bezahlt, die sie schreiben. Wer Hyprland benutzt hat und weiss, wie viel Arbeit darin steckt, wird schwerlich darüber klagen, dass der Entwickler jetzt davon leben kann. Und die MIT-Lizenz bleibt, was sie ist: Der Code lässt sich jederzeit forken.

Der Einwand stimmt – und trifft daneben. Forken lässt sich der Code, nicht die Marke, nicht die Infrastruktur, nicht der Plugin-Marktplatz mit inzwischen über 500 Einträgen und schon gar nicht der einzige bezahlte Vollzeitentwickler. Genau diese Teile hat die Stiftung übernommen. Die Erfahrung mit Distributionen unter Firmenkontrolle ist zudem nicht ermutigend: Bei Ubuntu hat sich die Kontrolle nicht über den Code durchgesetzt, sondern über den Paketkanal – nachzulesen in unserem Artikel dazu, warum wir Ubuntu nicht mehr empfehlen. Und dass Firmen ihre Position auch zugunsten der Nutzer korrigieren können, hat Balena bei Etcher gezeigt. Beides sind Argumente dafür, hinzuschauen, nicht dagegen.

Der Punkt ist nicht, dass Geld in freie Software fliesst. Der Punkt ist, dass mit dem Geld keine Regeln mitgeliefert wurden.

Was ihr tun könnt

• Wenn ihr Hyprland benutzt, spendet weiter direkt an das Projekt. Ein zweites Standbein ist der beste Schutz gegen die Abhängigkeit von einem einzigen Sponsor – und Spenden nimmt das Projekt laut Ankündigung ausdrücklich weiter an.
• Achtet in den kommenden Wochen darauf, ob Omacom Rechtsform, Statuten und Organe veröffentlicht. Das ist der Prüfstein. Eine Stiftung, die nach einem halben Jahr immer noch nur aus einer Ankündigung besteht, ist eine Kasse mit besserem Namen.
• Wenn ihr Omarchy einsetzt: Haltet eure Konfiguration in einem eigenen Git-Repository, unabhängig vom Plugin-Marktplatz. Was ihr selbst versioniert habt, überlebt jede Kursänderung des Projekts.
• Wer ein System sucht, dessen Trägerschaft seit Jahren offenliegt, findet es bei Debian oder bei den Community-Distributionen aus unserer Übersicht. Auch das Vorgehen von KDE Linux zeigt, dass ein neues Desktop-Projekt nicht zwingend acht Millionen und acht Namen braucht.

Fazit: Acht Millionen lösen das Geldproblem, nicht das Machtproblem

Omarchy hat in kurzer Zeit erreicht, wovon viele Linux-Projekte reden: eine grosse Nutzerbasis, ein erkennbares Gesicht, jetzt eine gesicherte Finanzierung. Für Hyprland ist die Nachricht handfest gut, weil ein Entwickler bezahlt wird, der die Arbeit ohnehin gemacht hat.

Der Vorgang zeigt trotzdem, wie schmal die Grundlage ist. Acht Personen aus demselben Milieu finanzieren eine Stiftung, deren Statuten nicht veröffentlicht sind, die Marken hält, aber nicht den Code, und die den zentralen Baustein der Oberfläche exklusiv an sich bindet, ohne den Begriff zu definieren. Das ist kein Skandal, und es unterstellt niemandem eine Absicht. Es ist schlicht eine Konstruktion, die vollständig auf gutem Willen ruht. Freie Software ist deshalb frei, weil sie sich nicht auf guten Willen verlassen muss.

Die nächste Meldung, auf die es sich zu warten lohnt, ist deshalb keine mit einer Zahl darin, sondern eine mit einem Reglement.

Quellen und weiterführende Links

• Omarchy News: Omacom Foundation launches with $8 million, 21.08.2026
• Omarchy News: Omacom Foundation to be exclusive Hyprland sponsor, 21.08.2026
• Omarchy News: The Omarchy Core Team, 19.08.2026
• Omarchy News: The first plugin competition, 19.08.2026, mit der Angabe zum Umfang des Plugin-Marktplatzes
• Quellcode von Omarchy auf GitHub, MIT-Lizenz, Konto basecamp
• Das Omarchy-Handbuch mit der Beschreibung als Arch- und Hyprland-Distribution
• Hyprland, Projektseite des Compositors
• Linuxiac zum Start von Hyprperks, Juli 2025, mit Preis und Leistungsumfang
• Linuxiac zur Stiftungsgründung, 23.08.2026

The post Omarchy: 8 Millionen Dollar und ein exklusiver Sponsor appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

An diesem Thema hat sich in den vergangenen zwei Jahren mehr geändert, als die meisten Anleitungen im Netz wiedergeben. Die Regel, dass eine Transaktion beim Senden ausdrücklich als ersetzbar markiert sein muss, gilt seit Bitcoin Core 28.0 nicht mehr. Und Core 31.0 hat im April 2026 an der Mechanik hinter CPFP geschraubt. Beides räumen wir hier mit ein.

Warum eine Transaktion überhaupt liegen bleibt

Miner suchen sich aus dem Mempool die Transaktionen mit der höchsten Gebühr je Byte heraus, nicht die mit der höchsten Gesamtgebühr. Massgeblich ist also der Satz in sat/vByte. Eine grosse Transaktion mit hoher Gesamtgebühr kann hinter einer kleinen mit niedriger Gesamtgebühr zurückstehen, wenn deren Satz besser ist. Wie sich Grösse und Satz berechnen, haben wir in Bitcoin Onchain Gebühren einfach berechnen ausführlich vorgerechnet; das wiederholen wir hier nicht.

Bleibt eine Transaktion unter dem Satz, den die Miner gerade bedienen, wartet sie. Und sie wartet nicht ewig: Bitcoin Core wirft unbestätigte Transaktionen nach einer eingestellten Frist wieder aus dem Mempool. Die Vorgabe steht im Quelltext bei DEFAULT_MEMPOOL_EXPIRY_HOURS{336}, also bei 336 Stunden oder rund zwei Wochen. Danach ist die Transaktion weg, als hätte es sie nie gegeben, und ihr könnt die Bitcoin normal wieder ausgeben. Die verbreitete Angabe von drei bis vier Wochen stimmt nicht.

Bitcoin Gebühr nachträglich erhöhen: RBF oder CPFP

Die beiden Verfahren lösen dasselbe Problem auf entgegengesetztem Weg, und die Wahl zwischen ihnen ist meistens keine Geschmacksfrage, sondern hängt davon ab, ob ihr Absender oder Empfänger seid.

Ein Punkt aus der Grafik verdient es, ausgesprochen zu werden, weil er in vielen Anleitungen untergeht: RBF ist der günstigere Weg. Bei der Ersetzung zahlt ihr am Ende nur die Gebühr der neuen Transaktion, die alte wird nie bestätigt und kostet deshalb auch nichts. Bei CPFP zahlt ihr beide Gebühren, und ihr belegt zusätzlich Platz in einem Block, den ihr sonst nicht gebraucht hättet. Wenn ihr die Wahl habt, nehmt RBF.

Damit ist auch eine falsche Vorstellung erledigt, die sich hartnäckig hält: Ihr bekommt die Gebühr der ersetzten Transaktion nicht „zurück". Es gibt nichts zurückzuerstatten, weil sie nie abgebucht wurde. Eine Bitcoin-Gebühr entsteht erst in dem Moment, in dem ein Miner die Transaktion in einen Block aufnimmt.

RBF: Was 2024 und 2025 gekippt ist

Replace by Fee heisst: Ihr gebt eine zweite Transaktion heraus, die dieselben Eingänge ausgibt wie die erste, aber eine höhere Gebühr trägt. Die Nodes werfen die alte aus dem Mempool und behalten die neue. Weil beide dieselben Eingänge verbrauchen, kann am Ende nur eine von beiden in einen Block. Doppelt ausgeben lässt sich damit also nichts.

Jahrelang galt dafür eine Bedingung, die den ganzen Mechanismus zur Glückssache machte: Die ursprüngliche Transaktion musste sich beim Senden als ersetzbar zu erkennen geben, über einen Wert im sequence-Feld unterhalb von 0xfffffffe. Wer das versäumt hatte, kam an RBF nicht heran.

Diese Bedingung ist gefallen. Bitcoin Core 28.0 hat am 02.10.2024 die Vorgabe für -mempoolfullrbf von 0 auf 1 gestellt. Ein halbes Jahr später, mit Core 29.0 vom 14.04.2025, ist der Schalter ganz verschwunden — die Release Notes schreiben dazu: „With widespread adoption of this policy, users no longer benefit from disabling it, so the option has been removed, making full replace-by-fee the standard behavior." In der Policy-Dokumentation stehen die früheren Regeln 1 und 2 folgerichtig als „(Removed)".

Für euch heisst das zweierlei. Als Absender könnt ihr praktisch jede unbestätigte Transaktion nachbessern, unabhängig davon, wie sie herausgegangen ist. Als Empfänger solltet ihr eine unbestätigte Zahlung grundsätzlich als noch nicht endgültig behandeln — auch eine, die formal nicht als ersetzbar markiert ist. Wer Waren gegen null Bestätigungen herausgibt, geht heute ein grösseres Risiko ein als 2023.

Die Regeln, die eine Ersetzung erfüllen muss

Übrig geblieben sind vier Bedingungen, und sie stehen so in der Policy-Dokumentation von Bitcoin Core:

1. Die Ersatztransaktion zahlt eine absolute Gebühr, die mindestens so hoch ist wie die Summe der Gebühren aller Transaktionen, die sie verdrängt.
2. Die zusätzliche Gebühr deckt darüber hinaus die eigene Bandbreite zum Incremental Relay Feerate der Node ab. Die Dokumentation rechnet es vor: für 500 vByte bei 0,1 sat/vByte sind das mindestens 50 Satoshi obendrauf.
3. Die verdrängten Transaktionen verteilen sich auf höchstens 100 Cluster.
4. Das Feerate-Diagramm des Mempools muss sich durch die Ersetzung strikt verbessern. Diese Regel kam mit dem Cluster-Mempool in Core 31.0 dazu und ersetzt die frühere reine Gebührenprüfung. Für gewöhnliche Zahlungen ist sie unauffällig: Laut Release Notes reicht es, dass die neue Transaktion eine höhere Gebühr und eine höhere Gebührenrate hat als die alte.

Drei Behauptungen, die ihr getrost vergessen könnt

Rund um RBF kursieren Regeln, die es nie gab. Weil sie in älteren Anleitungen stehen — auch in der ersten Fassung dieses Artikels —, hier die Richtigstellung.

• „Die Empfänger und Beträge müssen gleich bleiben." Falsch. Die Ausgänge dürfen frei geändert werden, auch die Empfängeradresse. Genau das ist der Grund, warum Wallets eine Funktion zum Stornieren einer unbestätigten Zahlung anbieten können: Sie ersetzen die Transaktion durch eine, die alles an euch selbst zurückschickt.
• „Ihr müsst die Gebühr verdreifachen, um sie zu verdoppeln." Falsch, und es vermengt absoluten Betrag und Rate. Es gilt Regel 1 plus Regel 2: mindestens die alte absolute Gebühr, plus ein kleiner Aufschlag für die Bandbreite.
• „Nicht alle Miner unterstützen RBF." Überholt. Ersetzungen werden von den Nodes im Netz weitergereicht; ein Miner sieht schlicht die teurere Variante und nimmt sie, weil sie mehr einbringt. Seit dem Wegfall des Schalters in Core 29.0 gibt es dazu auch keine sinnvolle Gegenkonfiguration mehr.

CPFP: Anhängen statt ersetzen

Child Pays for Parent braucht keine Erlaubnis vom Absender, denn es rührt die festhängende Transaktion gar nicht an. Ihr gebt stattdessen einen ihrer Ausgänge weiter aus — an euch selbst genügt — und stattet diese neue Transaktion mit einer hohen Gebühr aus. Weil das Kind nur bestätigt werden kann, wenn die Eltern mit im Block sind, bewerten Miner beide zusammen als Paket.

Deshalb funktioniert CPFP auch dann, wenn euch jemand anderes eine zu billige Zahlung geschickt hat. Ihr müsst nur über einen Ausgang verfügen können. Umgekehrt ist CPFP auch der Ausweg für Absender ohne Wechselgeld: Wer den gesamten Betrag verschickt hat, hat keinen eigenen Ausgang, an dem sich für eine Ersetzung drehen liesse.

Die Paketgebühr rechnen

Der Fehler, den hier fast alle machen: Sie setzen für das Kind den Zielsatz ein. Das reicht nicht. Der Zielsatz muss für das Paket herauskommen, und die zu billigen Eltern ziehen den Schnitt nach unten. Die Rechnung geht so:

Zielgebuehr Paket = (Groesse Eltern + Groesse Kind) * Zielsatz
Gebuehr Kind      = Zielgebuehr Paket - bereits gezahlte Gebuehr Eltern
Satz Kind         = Gebuehr Kind / Groesse Kind

Beispiel aus der Grafik:
  Eltern  140 vB, 6 sat/vB   ->   840 sat bereits gezahlt
  Kind    110 vB
  Ziel    25 sat/vB

  (140 + 110) * 25 = 6250 sat fuer das Paket
  6250 - 840       = 5410 sat muss das Kind tragen
  5410 / 110       = 49,2 sat/vB  ->  aufgerundet 50 sat/vB

Merkt euch die Faustregel dahinter: Je kleiner das Kind im Verhältnis zu den Eltern, desto brutaler muss sein Satz ausfallen. Ein 110-vByte-Kind, das 140 vByte Eltern mitschleppt, braucht den doppelten Zielsatz. Wallets mit CPFP-Funktion rechnen das selbst; wer von Hand baut, sollte grosszügig aufrunden.

Was Core 31.0 an CPFP geändert hat

Für gewöhnliche Zahlungen ändert sich nichts. Wer eine Lightning-Node betreibt, sollte den Punkt trotzdem kennen. Es gab in Bitcoin Core eine Sonderregel namens CPFP Carve-out, die einer einzelnen Transaktion erlaubte, die Paketgrenzen leicht zu überschreiten, sofern sie nur einen unbestätigten Vorgänger hatte. Sie war für Verträge zwischen zwei Parteien gedacht — also genau für Lightning-Kanäle — damit beide Seiten eine Gebühr nachschieben können, ohne dass eine die andere blockiert.

Diese Sonderregel ist mit Core 31.0 entfallen. Die Release Notes halten fest, dass Anwendungsfälle mit ähnlichem Bedarf „employ TRUC transactions and sibling eviction instead going forward". TRUC steht für Topologically Restricted Until Confirmation und ist in BIP 431 beschrieben, der weiterhin den Status Draft trägt. Praktisch betrifft das die Lightning-Implementierung, nicht euch als Nutzer — aber es ist ein guter Grund, die Node-Software aktuell zu halten, statt sie drei Versionen zurückhängen zu lassen.

Welche Wallet kann was

Die Verfahren nützen euch nur, wenn eure Wallet sie anbietet. Von Hand eine Ersatztransaktion zu bauen ist möglich, aber nichts, was wir jemandem empfehlen, der nicht ohnehin weiss, wie es geht. Die folgende Übersicht stützt sich auf die Dokumentation der Projekte selbst, Stand 23.08.2026.

Sparrow, auch mit einer BitBox02

Die Sparrow-Dokumentation nennt beide Wege. Für RBF muss die Transaktion unbestätigt sein und ausschliesslich eigene Eingänge verwenden; ersetzbar sendet Sparrow ohnehin von Haus aus. Unbestätigte Transaktionen bekommen im Reiter Transactions ein Symbol, und über den Rechtsklick führt Increase Fee zurück in den Sende-Dialog mit angepasster Gebühr. CPFP beschreibt die FAQ als das Ausgeben der Ausgänge zu einem höheren Satz.

Interessant ist das für alle mit einer BitBox02, denn die BitBoxApp selbst hat dafür keine Oberfläche. Der Hersteller sagt das offen und beschreibt in einer eigenen Anleitung den Umweg: „it doesn't have an RBF interface, it enables RBF for all transactions by default, giving you the option to use it with advanced software like Sparrow Wallet." Ihr verbindet die BitBox02 also mit Sparrow, wählt dort Increase Fee (RBF), schiebt den Regler hoch, bestätigt auf dem Gerät und sendet. Wie die Verbindung zu einer eigenen Node aussieht, steht in Sparrow Wallet mit Umbrel Bitcoin Fullnode verbinden und in Bitbox02 mit Raspiblitz Bitcoin Fullnode verbinden.

Bitcoin Core auf der Kommandozeile

Wer eine eigene Full Node betreibt, hat den direktesten Weg. Der RPC bumpfee nimmt die Transaktions-ID und baut die Ersetzung selbst:

# Gebuehr automatisch neu schaetzen lassen
bitcoin-cli bumpfee <txid>

# Oder den Satz selbst vorgeben, hier 25 sat/vByte
bitcoin-cli -named bumpfee txid=<txid> options='{"fee_rate": 25}'

Die Dokumentation beschreibt, wie Core die Mehrgebühr aufbringt: „The command will pay the additional fee by reducing change outputs or adding inputs when necessary. It may add a new change output if one does not already exist." Alle Eingänge der alten Transaktion wandern in die neue. Zwei Grenzen solltet ihr kennen: Der Befehl scheitert, wenn Wallet oder Mempool bereits eine Transaktion enthalten, die einen Ausgang der alten ausgibt — dann habt ihr faktisch schon ein CPFP gebaut. Und der angegebene Satz muss mindestens 1 sat/vByte über dem alten liegen.

Lightning-Node über Ride the Lightning

Hängt eine Kanaleröffnung fest, wird es unangenehm, weil der Kanal bis zur Bestätigung nicht nutzbar ist. RTL reicht dafür den BumpFee-Aufruf von LND durch, und der entscheidet selbst, welches Verfahren passt. Die LND-Dokumentation formuliert es so: „Depending on whether the outpoint has been registered in the sweeper (an existing input, e.g., an anchor output) or not (a new input, e.g., an unconfirmed wallet utxo), this will either be an RBF or CPFP attempt." Ihr müsst euch also nicht entscheiden, sondern nur einen Zielsatz angeben.

Der dritte Weg: Beschleuniger

Bleibt der Fall, in dem weder RBF noch CPFP geht: Ihr seid nicht der Absender und habt auch keinen Ausgang, über den ihr verfügen könnt. Dann bleibt ein Mining-Pool, der die Transaktion aus Kulanz in seinen nächsten Block nimmt. ViaBTC betreibt so einen Dienst weiterhin und nennt in seinem Hilfeartikel die Bedingungen: „ViaBTC supports 20 FREE acceleration chances per hour", dazu höchstens 0,5 KB Transaktionsgrösse und ein Mindestsatz. Wie das abläuft, steht in Bitcoin Transaktionen mit ViaBTC gratis beschleunigen.

Seid euch dabei über die Grenzen im Klaren. Ein Beschleuniger ändert nichts an der Transaktion und nichts an ihrer Gebühr — er bittet einen einzelnen Pool um Vorzugsbehandlung. Findet dieser Pool in absehbarer Zeit keinen Block, passiert nichts. Es ist die schwächste der drei Optionen und die einzige, bei der ihr auf das Wohlwollen eines Dritten angewiesen seid.

Was ihr tun könnt

• Erst nachsehen, dann handeln. Sucht die Transaktions-ID in einem Mempool-Explorer und vergleicht euren Satz mit dem, was gerade in die Blöcke geht. Liegt ihr knapp darunter, lohnt oft schon das Abwarten der nächsten ruhigen Stunde.
• Seid ihr der Absender, nehmt RBF. Es ist günstiger als CPFP und braucht seit Core 28.0 keine Vorbereitung mehr an der ursprünglichen Transaktion.
• Seid ihr der Empfänger, nehmt CPFP — und rechnet den Satz für das Paket, nicht für das Kind allein. Sonst zahlt ihr mehr und hängt trotzdem fest.
• Setzt einmalig den richtigen Satz, statt zweimal zu bieten. Jede Nachbesserung kostet erneut die volle Gebühr. Ein zu vorsichtiger Bump, der wieder nicht reicht, ist der teuerste Fehler in diesem Vorgang.
• Behandelt eingehende Zahlungen mit null Bestätigungen als offen. Seit Full-RBF Standard ist, lässt sich jede unbestätigte Transaktion ersetzen, auch eine ohne Markierung.
• Beugt vor mit UTXO-Management. Wer wenige, saubere UTXO hält, baut kleinere Transaktionen — und kleinere Transaktionen sind bei gleichem Satz schlicht billiger, auch beim Nachbessern.
• Prüft vor dem Wallet-Wechsel, ob sie es kann. Die Tabelle oben ist ein Anfang; Welche Bitcoin Wallets gibt es ordnet die Kandidaten breiter ein.

Fazit: Eine festhängende Transaktion ist ein Ärgernis, kein Verlust

Der schlimmste Fall ist, dass ihr zwei Wochen wartet und die Bitcoin danach wieder in eurer Wallet liegen. Alles darunter lässt sich mit einem der beiden Verfahren beheben, und in den meisten Wallets sind es zwei Klicks.

Bemerkenswert ist, wie deutlich sich die Lage seit 2023 gebessert hat. Damals war RBF eine Funktion, an die ihr im Nachhinein nur herankamt, wenn ihr vorher daran gedacht hattet — und dieses Vorher-Daran-Denken übernahmen längst nicht alle Wallets. Heute ist die Ersetzbarkeit der Normalzustand des Netzes, und die Frage lautet nur noch, ob eure Wallet eine Schaltfläche dafür hat. Dass Bitcoin Core dafür eine jahrelang umstrittene Option kommentarlos gestrichen hat, statt sie zur Wahl zu stellen, war die richtige Entscheidung: Eine Regel, die sich mit ein paar Zeilen Konfiguration umgehen liess, hat nie Sicherheit gestiftet, sondern nur den Anschein davon.

Wer daraus etwas mitnehmen will, dann dies: Verlasst euch nicht auf null Bestätigungen, weder als Empfänger noch beim Kaffeeholen mit dem Handy. Und wenn ihr sendet, schaut einmal kurz auf den Mempool, bevor ihr auf Senden drückt. Das erspart euch diesen ganzen Artikel.

Quellen und weiterführende Links

• Bitcoin Core: doc/policy/mempool-replacements.md — die geltenden Ersetzungsregeln
• Bitcoin Core 28.0 Release Notes — Vorgabe für -mempoolfullrbf von 0 auf 1
• Bitcoin Core 29.0 Release Notes — Option entfernt, Full-RBF ist Standard
• Bitcoin Core 31.0 Release Notes — Feerate-Diagramm und Wegfall des CPFP Carve-out
• Bitcoin Core: mempool_options.h — DEFAULT_MEMPOOL_EXPIRY_HOURS{336}
• Bitcoin Core RPC-Referenz: bumpfee
• BIP 431: Topology Restrictions for Pinning — TRUC-Transaktionen
• Bitcoin Optech: CPFP carve out
• Sparrow Wallet FAQ — Increase Fee und CPFP
• Electrum FAQ — Increase Fee, Child pays for parent, Cancel
• BitBox Support: RBF mit Sparrow und BitBox02
• LND API: BumpFee
• ViaBTC: BTC Transaction Accelerator

The post Bitcoin Gebühr nachträglich erhöhen mit RBF und CPFP appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Digital Markets Act gilt in der Schweiz nicht. Das ist bekannt. Weniger bekannt ist, was daraus praktisch folgt und wie wenig die Schweiz dagegen in der Hand hat — auch nicht mit den zwei grossen Regulierungsvorhaben, die derzeit laufen. Beide gehen an der Sache vorbei, und zwar nicht aus Versehen.

Was der Digital Markets Act vorschreibt — und was er mit dem DSA nicht zu tun hat

Brüssel hat 2022 zwei Verordnungen beschlossen, die gerne in einem Atemzug genannt und dabei regelmässig verwechselt werden. Der Digital Services Act regelt, was auf Plattformen gesagt und gelöscht werden darf, mit Meldewegen, Moderationspflichten und Trusted Flaggern. Wir haben ihn hier ausführlich und nicht wohlwollend behandelt. Der Digital Markets Act regelt etwas völlig anderes: nicht Inhalte, sondern Marktmacht.

Er benennt eine Handvoll Konzerne als Torwächter und legt ihnen Pflichten auf, die vorher gelten und nicht erst nach jahrelangen Verfahren. Die Kommission fasst sie so zusammen: Torwächter dürfen ihre eigenen Dienste im Ranking nicht bevorzugen, dürfen Nutzer nicht daran hindern, vorinstallierte Software zu deinstallieren, müssen Dritten in bestimmten Fällen Interoperabilität gewähren und müssen Geschäftskunden erlauben, ihre Angebote auch ausserhalb der Plattform zu bewerben. Dazu kommt die Pflicht, Endnutzer bei der ersten Nutzung aktiv wählen zu lassen, welche Suchmaschine, welchen Browser und welchen Sprachassistenten sie wollen, statt ihnen eine Voreinstellung unterzuschieben. Genau das ist der Auswahlbildschirm, den es in der Schweiz seit diesem Sommer nicht mehr gibt.

Der Unterschied zwischen den beiden Verordnungen ist kein juristisches Detail. Der DSA greift in die Rede ein, der DMA in den Markt. Wer beide für dasselbe hält, kann nicht erklären, warum sich das eine ablehnen und das andere trotzdem vermissen lässt.

890 Millionen Euro und 60 Tage: so sieht Durchsetzung im DMA aus

Der Bussenentscheid vom 23. Juli 2026 zerfällt in zwei Teile. 460 Millionen Euro entfallen auf Selbstbevorzugung in der Google-Suche: Google zeigt eigene Dienste prominenter an, «including at the top of the search results page or by using enhanced visuals and filters». 430 Millionen Euro entfallen auf Google Play, weil App-Entwickler ihre Kunden nicht auf «alternative, often cheaper, purchase channels» hinweisen durften und die Gebühren für solche Verweise überhöht waren. Die Pressemitteilung der Kommission hält fest: «Google is required to comply with the Commission's decisions within 60 days.» Danach drohen Zwangsgelder von bis zu fünf Prozent des weltweiten Tagesumsatzes.

Rechnet nach: 60 Tage ab dem 23. Juli endet am 21. September 2026. Bis dahin muss Google die Suchergebnisseite umgebaut haben, oder es wird teuer. Das ist der entscheidende Punkt an diesem Instrument — nicht die Höhe der Busse, sondern die Uhr, die mit ihr zu laufen beginnt.

Der Auswahlbildschirm verschwand, kaum war das Urteil rechtskräftig

Die Vorgeschichte reicht acht Jahre zurück. 2018 verhängte die Kommission gegen Google eine Busse wegen missbräuchlicher Praktiken rund um Android. Der Streit ging durch alle Instanzen und endete am 2. Juli 2026: Der Gerichtshof der Europäischen Union wies das Rechtsmittel in der Rechtssache C-738/22 P ab und bestätigte 4'125'000'000 Euro, davon 1'520'605'895 Euro solidarisch für Alphabet. Beanstandet wurden Vorinstallationsvereinbarungen, Anti-Fragmentierungsklauseln und Umsatzbeteiligungen, die daran hingen, keinen konkurrierenden Suchdienst vorzuinstallieren.

Zwölf Tage nach diesem Urteil meldete das WEKO-Sekretariat, Google habe den Auswahlbildschirm in der Schweiz abgeschafft, während er im Europäischen Wirtschaftsraum weiter besteht. Schweizer Nutzer bekommen bei der Ersteinrichtung keinen Auswahlbildschirm mehr, Google Search ist gesetzt. Ob zwischen dem Urteil und der Abschaffung ein Zusammenhang besteht, hat Google öffentlich nicht erklärt, und wir behaupten es nicht. Die Reihenfolge steht trotzdem fest, und sie ist bemerkenswert: Sobald die europäische Pflicht endgültig geklärt war, verschwand die Wahlmöglichkeit dort, wo keine Pflicht besteht.

Das ist die praktische Bedeutung eines fehlenden Gesetzes. Freiwilligkeit hält genau so lange, wie sie nichts kostet.

Eine Vorabklärung kann gar keine Busse aussprechen

Ein Teil der Berichterstattung im Juli sprach von einer «Untersuchung gegen Google». Das trifft nicht zu, und der Unterschied ist erheblich. Das Sekretariat hat eine Vorabklärung eröffnet. Was das ist, beschreibt die WEKO in ihrem eigenen Merkblatt zum Ablauf einer Vorabklärung mit erfrischender Klarheit.

Zur Frage, ob am Ende eine Sanktion stehen kann, heisst es dort: «Nein. In der Vorabklärung wird nicht abschliessend beurteilt, ob das Verhalten zulässig oder unzulässig ist. Folglich können weder das Sekretariat noch die WEKO eine Geldsanktion aussprechen.» Zur Dauer: «Die Dauer einer Vorabklärung ist je nach Einzelfall ganz verschieden; sie kann von mehreren Monaten bis zu gut über einem Jahr dauern.» Und zum Ausgang: Sie kann folgenlos eingestellt werden, in einer einvernehmlichen Verhaltensanpassung enden oder in eine förmliche Untersuchung nach Art. 27 ff. Kartellgesetz münden — die dann ihrerseits Jahre dauert.

Stellt das neben die 60 Tage aus Brüssel. Auf der einen Seite ein Verfahren mit Frist, Busse und Zwangsgeld. Auf der anderen ein Vorverfahren ohne Frist, ohne Sanktionsmöglichkeit und mit offenem Ausgang, das schon vom Namen her nur klärt, ob überhaupt ein Verfahren zu eröffnen wäre. Das ist kein Vorwurf an die WEKO. Sie tut, was ihr das Gesetz erlaubt. Das Gesetz erlaubt nur wenig.

Kartellrecht kommt hinterher, der DMA kommt vorher

Hier liegt der strukturelle Kern. Kartellrecht arbeitet im Nachhinein: Ein Unternehmen verhält sich, eine Behörde stellt Jahre später fest, ob das zulässig war. Der Android-Fall ist das Lehrstück dazu — acht Jahre von der Kommissionsentscheidung bis zur Rechtskraft, und in dieser Zeit hat sich das beanstandete Geschäftsmodell längst weiterentwickelt.

Der DMA dreht das um. Er stellt keine Missbrauchsfrage, sondern eine Statusfrage: Wer als Torwächter benannt ist, muss bestimmte Dinge tun und andere lassen, unabhängig davon, ob im Einzelfall ein Missbrauch nachweisbar wäre. Deshalb dauert die Durchsetzung Monate statt Jahre. Das lässt sich als gefährliche Machtverschiebung zugunsten der Kommission lesen — dieses Argument nehmen wir ernst und kommen darauf zurück. Es funktioniert aber nachweislich dort, wo Kartellrecht seit zwei Jahrzehnten nicht mehr rechtzeitig ankommt.

Die Schweiz hat 2022 immerhin einen Schritt in diese Richtung getan: Seit dem 1. Januar 2022 kennt das Kartellgesetz in Art. 4 Abs. 2bis und Art. 7 den Begriff der relativen Marktmacht. Sie liegt laut dem Merkblatt der WEKO vor, wenn «Nachfrager und Nachfragerinnen oder Anbieter und Anbieterinnen von Waren und Dienstleistungen mangels angemessener Alternativen von einem Unternehmen abhängig sind». Das klingt zunächst brauchbar. Nur steht im selben Merkblatt der entscheidende Satz: «Auf die Vorschriften zur relativen Marktmacht können sich Unternehmen im Sinne des Kartellgesetzes berufen» — Konsumenten ausdrücklich nicht. Wer als Privatperson keinen Auswahlbildschirm mehr bekommt, hat aus diesem Instrument nichts.

Die Kartellgesetz-Revision regelt Fusionen, nicht Plattformen

Das Kartellgesetz wird gerade revidiert, und wer nun hofft, dort komme die Antwort auf die Plattformfrage, wird enttäuscht. Das Parlament hat die Teilrevision am 19. Dezember 2025 verabschiedet. Am 27. Mai 2026 hat der Bundesrat die Vernehmlassung zu den Ausführungsverordnungen eröffnet, die noch bis zum 17. September 2026 läuft. Umgesetzt wird laut Mitteilung «die vom Parlament beschlossene Gesetzesrevision im Hinblick auf die neue Zusammenschlusskontrolle, Parteienentschädigungen, das angepasste Widerspruchsverfahren und die Compliance Defense».

Das sind vernünftige Anliegen. Ein neuer Prüfmassstab für Unternehmenszusammenschlüsse, ein entschärftes Widerspruchsverfahren, eine Anrechnung von Compliance-Anstrengungen. Digitale Plattformen, Selbstbevorzugung, Interoperabilität oder Voreinstellungen kommen darin nicht vor. Die Revision modernisiert das Werkzeug, das ohnehin erst nach dem Schaden greift. Sie schafft kein Werkzeug, das vorher greift.

Das KomPG holt eine Hälfte der EU-Regulierung — die falsche

Das zweite grosse Vorhaben ist das Bundesgesetz über Kommunikationsplattformen und Suchmaschinen, kurz KomPG. Der Bundesrat hat den Vorentwurf am 29. Oktober 2025 in die Vernehmlassung geschickt, die Frist lief bis zum 16. Februar 2026. Erfasst werden «sehr grosse Kommunikationsplattformen und Suchmaschinen, weil diese aufgrund ihrer Reichweite die öffentliche Debatte und Meinungsbildung stark beeinflussen». Als sehr gross gilt, wer «monatlich durchschnittlich von zehn Prozent der ständigen Schweizer Wohnbevölkerung genutzt» wird, also rund 900'000 Nutzer.

Und was verlangt das Gesetz von diesen Diensten? Ein Meldeverfahren für mutmasslich rechtswidrige Inhalte. Eine Begründungspflicht bei Löschungen und Kontosperrungen. Ein internes Beschwerdeverfahren und aussergerichtliche Streitbeilegung. Transparenzvorgaben für Werbung und Empfehlungssysteme. Ein öffentliches Werbearchiv. Datenzugang für Verwaltung und Forschung. Eine Rechtsvertretung in der Schweiz.

Das ist, Punkt für Punkt, die Logik des Digital Services Act. Es ist die Regulierung der Rede. Von Selbstbevorzugung, Auswahlbildschirmen, Deinstallierbarkeit, alternativen App-Kanälen oder Interoperabilität steht nichts drin — nicht in abgeschwächter Form, sondern gar nicht. Die Schweiz übernimmt in eigener Fassung genau jenen Teil der europäischen Plattformregulierung, den auch wir hier für gefährlich halten, und lässt jenen Teil weg, der Nutzern Wahlmöglichkeiten zurückgibt.

In der Vernehmlassung wurde der Entwurf breit kritisiert, allerdings fast durchweg entlang der DSA-Achse. AlgorithmWatch CH fordert vier Ergänzungen, darunter, generative KI dort zu erfassen, «wo sie als Suchmaschinen oder Social-Media-Plattformen genutzt» wird, und eine Pflicht zur Risikominderung. Die Digitale Gesellschaft hält fest, «der zweite Teil – die Pflicht zu Risikominderungsmassnahmen – freiwillig» bleibe, und nennt die Werberegulierung «viel zu zahnlos». Beides sind berechtigte Einwände. Nur verhandelt auch diese Kritik über Moderation und Transparenz. Die Frage, warum die Vorlage kein einziges marktöffnendes Element enthält, hat in der Debatte kaum jemand gestellt.

Was Schweizer Nutzer heute schon nicht bekommen

Das bleibt abstrakt, solange es nicht auf konkrete Geräte heruntergebrochen ist. Also konkret. Apple beschreibt auf seiner eigenen Entwicklerseite, welche Änderungen der DMA ausgelöst hat: alternative App-Marktplätze und Web-Distribution, Frameworks für andere Browser-Engines als WebKit, ein Auswahlbildschirm für den Standardbrowser, NFC-Zugriff für Drittanbieter. Und dazu den Geltungsbereich: «The changes are available for developers who distribute apps in any of the 27 EU member countries and only apply to apps available and distributed to users in the EU.» Die Schweiz kommt in dem Dokument nicht vor.

Noch deutlicher steht es in Apples Support-Artikel zu alternativen App-Marktplätzen, in der Schweizer Fassung: «Alternative App-Anbieter sind in Brasilien, Japan und den Ländern bzw. Regionen der Europäischen Union verfügbar.» Wer sie nutzen will, dessen Apple-Konto muss auf ein solches Land eingestellt sein, und er muss sich physisch dort aufhalten. Die Schweiz steht nicht auf dieser Liste. Ein iPhone in Zürich installiert keine Apps ausserhalb des App Store, ein iPhone in Konstanz schon. Der Unterschied ist nicht technisch. Er ist rechtlich — und Apple erklärt ihn Schweizer Nutzern auf einer Seite, die ausdrücklich für sie geschrieben ist.

Dasselbe Muster bei Messengern. Meta hat im November 2025 Drittanbieter-Chats für WhatsApp angekündigt und schreibt dazu unmissverständlich: «The DMA requires Meta to give people using WhatsApp in Europe the option to connect with people using third-party messaging services», verfügbar «in line with DMA requirements» für Nutzer in der «European Region». Ob und wann Schweizer Konten dazugehören, sagt Meta in dieser Mitteilung nicht — was für sich genommen schon die Antwort ist, denn die Pflicht endet an der Grenze des Geltungsbereichs.

Drei Beispiele, ein Mechanismus: Wo eine Pflicht besteht, öffnen die Konzerne. Wo keine besteht, öffnen sie nicht, oder sie schliessen wieder.

Japan hat gezeigt, dass es auch ohne Brüssel geht

An dieser Stelle kommt üblicherweise der Einwand, die Schweiz könne eben nicht anders, weil sie nicht in der EU sei und keinen Binnenmarkt von 450 Millionen Menschen in die Waagschale werfe. Japan widerlegt das.

Japan hat mit dem Mobile Software Competition Act ein eigenes Gesetz geschrieben, dessen Leitlinien die Wettbewerbsbehörde JFTC im Juli 2025 veröffentlicht hat. In Kraft ist es seit dem 17. Dezember 2025. Google hat am selben Tag in seinem eigenen Unternehmensblog mitgeteilt, was das bedeutet: «Under the MSCA, we will show choice screens that prompt you to select a search engine and browser.» Dazu alternative Bezahloptionen für Entwickler und Käufe digitaler Inhalte ausserhalb von Google Play.

Lest den Satz noch einmal. «Under the MSCA» — wegen des Gesetzes. Nicht wegen Kundenwünschen, nicht wegen Marktdruck, nicht aus Einsicht. Und deshalb steht Japan heute in Apples Länderliste für alternative App-Marktplätze neben der EU und Brasilien, während die Schweiz fehlt. Japan hat 124 Millionen Einwohner, die Schweiz neun. Der Grössenunterschied ist real. Aber die Behauptung, ein Land ausserhalb der EU könne in dieser Frage grundsätzlich nichts ausrichten, ist damit widerlegt. Es ist eine Frage des politischen Willens, nicht der Grösse.

Die Gegenposition: Braucht die Schweiz das wirklich?

Gegen einen schweizerischen DMA lassen sich drei ernstzunehmende Argumente vorbringen, und sie verdienen eine Antwort statt eines Achselzuckens.

Erstens: Das Kartellgesetz reicht. Die WEKO ist tätig geworden, das Verfahren läuft, abwarten genügt. Der Einwand scheitert an den eigenen Unterlagen der Behörde. Eine Vorabklärung kann laut ihrem Merkblatt keine Sanktion aussprechen, hat keine Frist und kann folgenlos eingestellt werden. Selbst im günstigsten Fall — Untersuchung, Verfügung, Beschwerde ans Bundesverwaltungsgericht, Weiterzug ans Bundesgericht — reden wir über Jahre. Der Auswahlbildschirm ist inzwischen weg. Recht, das erst nach dem Ende des beanstandeten Verhaltens ankommt, ist für die Betroffenen kein Recht, sondern Statistik.

Zweitens: Regulierung schadet dem Standort. Auch dieses Argument hat Substanz — nur trifft es hier den Falschen. Die Adressaten des DMA sind sechs bis acht Konzerne mit weltweiter Marktmacht, kein Schweizer KMU. Und die Schweiz reguliert ohnehin bereits, das KomPG liegt vor. Zur Debatte steht nicht, ob reguliert wird, sondern was. Wer Regulierung grundsätzlich ablehnt, müsste konsequenterweise auch gegen das KomPG sein, das Plattformen Moderations- und Berichtspflichten auferlegt. Wer das KomPG für nötig hält, aber marktöffnende Pflichten für Teufelszeug, hat sich für die eingriffsintensivere Hälfte entschieden.

Drittens: Das wäre autonomer Nachvollzug und damit EU-Hörigkeit. Das ist der stärkste Einwand, und er verdient Respekt. Die Antwort steht im vorigen Abschnitt: Japan hat kein EU-Recht nachvollzogen, sondern ein eigenes Gesetz mit eigenen Kriterien und einer eigenen Behörde geschrieben. Ein schweizerischer Ansatz müsste den DMA nicht kopieren. Er müsste nur überhaupt existieren.

Wer die EU kritisiert, muss beim DMA trotzdem genau hinsehen

An dieser Stelle ist eine Selbstauskunft fällig, denn dieser Blog ist in EU-Fragen alles andere als unverdächtig. Wir haben die Chatkontrolle, die Altersverifikation, den digitalen Euro und den DSA scharf angegriffen und in einem eigenen Kommentar die These vertreten, dass dieser Apparat Demokratie als Fremdwort behandelt. An keinem Wort davon ist etwas zurückzunehmen.

Trotzdem gilt: Der DMA ist nicht der DSA. Der eine gibt der Kommission Zugriff darauf, was gesagt werden darf. Der andere zwingt Konzerne, Nutzern eine Wahl zu lassen, die sie ihnen sonst nehmen. Das eine lässt sich bekämpfen und das andere für richtig halten, ohne inkonsequent zu sein — vorausgesetzt, die Unterscheidung läuft nach Wirkung und nicht nach Absender. Die berechtigte Sorge bleibt, dass eine Behörde, die Marktstrukturen per Verordnung setzt, dieselbe Macht später anders einsetzt. Deshalb ist die entscheidende Frage an ein schweizerisches Pendant nicht, ob es kommt, sondern wer es durchsetzt und mit welcher gerichtlichen Kontrolle. Diese Frage wird derzeit gar nicht gestellt, weil das Thema nicht auf der Traktandenliste steht.

Das ist der eigentliche Befund dieses Sommers. Nicht, dass die Schweiz die falsche Antwort gegeben hätte. Sondern dass sie die Frage nicht stellt, während im selben Monat 890 Millionen Euro Busse, ein 60-Tage-Ultimatum und ein stillschweigend entfernter Auswahlbildschirm zeigen, worum es geht. Der Kommentar zur Kampagne Keep Android Open hat vor einem halben Jahr beschrieben, wie sich das Ökosystem schliesst. Der fehlende DMA ist der Grund, warum die Schweiz dabei nicht einmal zusieht, sondern schlicht nicht vorkommt.

Was ihr tun könnt

Politisch ist die Lage unbefriedigend, praktisch könnt ihr trotzdem einiges selbst in die Hand nehmen.

• Standardsuchmaschine von Hand setzen. Der fehlende Auswahlbildschirm nimmt euch nur die Frage ab, nicht die Möglichkeit. In Chrome unter Einstellungen, Suchmaschine, und in Firefox unter Einstellungen, Suchen lässt sich der Standard weiterhin ändern. Welche Anbieter dafür taugen, haben wir in unserer Übersicht zu den Alternativen zur Google-Suche zusammengestellt.
• App-Bezug vom Play Store lösen. Was der DMA in der EU erzwingt, könnt ihr euch in der Schweiz selbst bauen. Obtainium holt Apps direkt von den Release-Seiten der Entwickler, und die alternativen App-Stores decken den Rest ab. Wer weiter gehen will, findet im GrapheneOS-Einsteiger-Guide den Weg zu einem System, das gar nicht erst voreinstellt.
• An der laufenden Vernehmlassung teilnehmen. Die Verordnungen zum revidierten Kartellgesetz stehen noch bis zum 17. September 2026 offen. Stellungnahmen sind nicht Verbänden vorbehalten; jede Person und jede Organisation kann eine einreichen. Wer festhält, dass die Vorlage digitale Torwächter nicht erfasst, bringt diese Lücke wenigstens ins Protokoll.
• Der WEKO Sachverhalte melden. Das Sekretariat wird auch auf Hinweise Dritter tätig. Wer den Wegfall des Auswahlbildschirms auf einem konkreten Gerät dokumentiert hat, mit Modell, Datum und Screenshot, liefert brauchbares Material. Für Unternehmen gibt es zusätzlich das Meldeformular zur relativen Marktmacht — Privatpersonen können sich auf diese Bestimmung nicht berufen, Hinweise geben aber sehr wohl.
• Beim Gerätekauf mitdenken. Wenn Öffnung an Rechtsräumen hängt, ist die Plattformwahl eine politische Entscheidung. Ein Android-Gerät mit entsperrbarem Bootloader lässt euch Alternativen offen. Ein Gerät, das Software ausschliesslich aus einem Store des Herstellers annimmt, überlässt eure Wahlfreiheit einer Rechtsordnung, in der ihr nicht wohnt.

Fazit: Die Schweiz reguliert die Rede und lässt den Markt laufen

Es gibt in der schweizerischen Digitalpolitik derzeit zwei grosse Baustellen. Das KomPG regelt, wie Plattformen mit Inhalten umgehen müssen. Die Kartellgesetz-Revision regelt Unternehmenszusammenschlüsse. Beides ist begründbar. Beides hilft niemandem, dem Google im Juli die Suchmaschinenauswahl weggenommen hat.

Die Schweiz hat sich damit, ohne dass es je zur Debatte stand, für die eingriffsintensive Hälfte der europäischen Plattformregulierung entschieden und gegen die befreiende. Sie übernimmt Meldeverfahren, Löschbegründungen und Werbearchive nach dem Muster des DSA — und lässt Selbstbevorzugung, Voreinstellungen, Interoperabilität und alternative Vertriebswege unberührt. Das Ergebnis ist ein Land, in dem Konzerne sagen müssen, warum sie einen Beitrag gelöscht haben, aber niemandem erklären müssen, warum sie eine Wahlmöglichkeit gestrichen haben.

Am 21. September läuft in Brüssel die Frist für Google ab. In Bern läuft am 17. September die Vernehmlassung zu Verordnungen aus, in denen digitale Plattformen nicht vorkommen. Zwei Termine in derselben Woche, zwei Vorstellungen davon, was Wettbewerbsrecht im Jahr 2026 leisten soll. Es steht zu befürchten, dass nur eine davon Wirkung zeigt.

Quellen und weiterführende Links

• SECO/WEKO: Das Sekretariat der WEKO ermittelt gegen Google, Medienmitteilung vom 14. Juli 2026
• WEKO: Merkblatt zum Ablauf einer Vorabklärung (PDF)
• WEKO: Merkblatt und Meldeformular relative Marktmacht (PDF, Art. 4 Abs. 2bis und Art. 7 KG)
• Europäische Kommission: Commission fines Google €890 million for breaches of the Digital Markets Act, 23. Juli 2026
• Europäische Kommission: Pressemitteilung IP/26/1670 (PDF)
• Gerichtshof der EU: Pressemitteilung zum Urteil C-738/22 P (Google Android), 2. Juli 2026 (PDF)
• Verordnung (EU) 2022/1925 (Digital Markets Act) auf EUR-Lex
• Europäische Kommission: About the Digital Markets Act
• Bundesrat: Neues Gesetz über Kommunikationsplattformen und Suchmaschinen — Start der Vernehmlassung, 29. Oktober 2025
• Bundesrat: Kartellgesetz — Vernehmlassung zur Revision der Verordnungen, 27. Mai 2026
• AlgorithmWatch CH: Vernehmlassungsantwort zum KomPG
• Digitale Gesellschaft: Plattformregulierung — der späte und zahme Aufbruch des Bundesrats, 30. Oktober 2025
• AlgorithmWatch CH: Regulierung von Online-Plattformen — was tut die Schweiz?
• Apple Developer: Changes for apps in the European Union
• Apple Support: Informationen zu alternativen App-Anbietern (Schweizer Fassung)
• Meta: Messaging Interoperability — WhatsApp enables third-party chats for users in Europe, November 2025
• Google: Complying with Japan's Mobile Software Competition Act, 17. Dezember 2025
• JFTC: Mobile Software Competition Act Guidelines, Juli 2025 (PDF, englische Arbeitsübersetzung)

The post Digital Markets Act: Die Schweiz reguliert das Falsche appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Überwachungskamera ohne Cloud: das eine Kriterium, das wirklich zählt

Der Markt ist voll von Geräten, die mit «lokaler Speicherung» und «kein Abo nötig» werben und trotzdem ohne den Hersteller nicht funktionieren. Der Grund ist simpel: Eine SD-Karte im Gehäuse ist lokale Speicherung. Erreichbar ist sie trotzdem nur über die Hersteller-App, und die verbindet sich über die Hersteller-Server. Wenn der Anbieter den Dienst einstellt, die App aus dem Store nimmt oder das Konto sperrt, habt ihr ein Stück Plastik an der Wand.

Das einzige belastbare Kaufkriterium für eine Überwachungskamera ohne Cloud lautet deshalb: Die Kamera muss eigenständig als Videoquelle und als Gerät ansprechbar sein — als RTSP-Stream und über ONVIF. «Eigenständig» heisst: ohne Hersteller-Hub, ohne Hersteller-Konto, ohne Internetverbindung. Alles andere — Auflösung, Nachtsicht, Personenerkennung, Design — ist nachgelagert. Eine 4K-Kamera ohne RTSP ist für den lokalen Betrieb wertlos, eine 2K-Kamera mit RTSP taugt.

Dass das mehr ist als Prinzipienreiterei, zeigt ein Fall vom März 2025: Die US-Behörde CISA veröffentlichte für die IP-Kamera Edimax IC-7100 eine Sicherheitswarnung mit CVSS-v4-Wert 9,3 — eine Befehlsinjektion in allen Firmware-Versionen. Dazu der entscheidende Satz: «Edimax has not responded to CISA requests to coordinate the vulnerability.» Es gibt keinen Patch. CISA empfiehlt stattdessen, solche Geräte gar nicht erst aus dem Internet erreichbar zu machen — und genau das könnt ihr nur bei einer Kamera, die ohne Hersteller-Cloud arbeitet.

RTSP, ONVIF, NVR: die drei Begriffe, ohne die ihr kein Datenblatt lesen könnt

Diese drei Wörter tauchen in jedem Datenblatt auf, und die wenigsten Produktseiten erklären sie. Ohne sie ist der Rest dieses Artikels nicht zu verstehen, deshalb zuerst die Grundlagen — kurz, und danach nicht mehr.

RTSP ist die Fernbedienung, nicht das Bild

Das Real Time Streaming Protocol ist in RFC 2326 vom April 1998 festgeschrieben und benutzt standardmässig Port 554. Wichtig ist, was es nicht tut: Der RFC beschreibt RTSP als «network remote control» und hält ausdrücklich fest, dass das Protokoll die Videodaten typischerweise nicht selbst überträgt — «Data is carried out-of-band by a different protocol», in der Praxis RTP.

Für euch heisst das: RTSP ist die Adresse, unter der ein Programm den Stream abholen kann. Sie sieht typischerweise so aus, hier am Beispiel der offiziellen Tapo-Dokumentation von TP-Link:

rtsp://benutzer:passwort@192.168.20.41/stream1   # Hauptstream, volle Auflösung
rtsp://benutzer:passwort@192.168.20.41/stream2   # Substream, kleinere Auflösung

Wer eine solche URL hat, kann das Bild in VLC, in ein NAS, in einen NVR, in Frigate oder in Home Assistant holen — ganz ohne Hersteller. Wer keine hat, kann das nicht, und keine Software der Welt ändert daran etwas.

ONVIF macht aus dem Stream ein Gerät

RTSP liefert Bild und Ton. ONVIF liefert alles andere: Gerätesuche im Netz, Auslesen der verfügbaren Streams, Bildeinstellungen, Schwenken und Neigen, und vor allem Ereignisse — Bewegungsalarm, Sabotagealarm, Metadaten. ONVIF Profile T schreibt für Geräte unter anderem Metadaten-Streaming vor und deckt H.264 wie H.265 ab.

Der praktische Unterschied: Mit RTSP allein habt ihr ein Bild, das rund um die Uhr aufgezeichnet wird und dessen Bewegungserkennung das NAS oder der NVR rechnen muss. Mit ONVIF meldet die Kamera selbst, wann sich etwas bewegt hat — ereignisgesteuerte Aufnahmen statt endlosem Dauerband.

NVR, NAS oder Software — wo die Aufnahme landet

Ein NVR (Network Video Recorder) ist eine Kiste, die nichts anderes tut als Kamerastreams entgegennehmen, aufzeichnen und wiedergeben. Ein NAS ist ein allgemeiner Dateiserver, der das per Zusatzsoftware auch kann — bei Synology heisst sie Surveillance Station. Und dann gibt es reine Software wie Frigate oder Shinobi, die auf beliebiger Hardware läuft.

Der Unterschied liegt bei Kosten und Bindung. Ein NAS habt ihr vielleicht schon — dann kostet die Aufnahme nur noch Lizenzen: Synology legt zwei Standardlizenzen bei, jede weitere Kamera braucht ein Lizenzpaket für 1, 4 oder 8 Geräte. Software ist lizenzfrei, verlangt dafür Einarbeitung. Alle drei Wege setzen dasselbe voraus: RTSP, besser noch ONVIF.

Warum «ONVIF-kompatibel» auf der Verpackung nichts beweist

ONVIF ist kein Gütesiegel zum Selbstbedienen, sondern ein Konformitätsverfahren. Hersteller müssen ihr Gerät mit dem offiziellen Testwerkzeug prüfen, Unterlagen einreichen und werden danach in der Datenbank der konformen Produkte geführt; die Konformität hängt dabei an einer konkreten Firmware-Version. ONVIF weist auf derselben Seite ausdrücklich darauf hin, dass Hersteller keine Konformität behaupten dürfen, ohne das Verfahren abgeschlossen zu haben, und bittet um Meldung, wenn ein Produkt sich als konform bezeichnet, aber nicht in der Datenbank steht.

Damit habt ihr einen Prüfschritt, der nichts kostet: Modellname in die Datenbank eintippen. Steht es dort, wisst ihr auch gleich, welches Profil gilt. Steht es nicht dort, ist «ONVIF-kompatibel» eine Behauptung ohne Deckung.

Das Profil selbst ist 2026 ein eigenes Kaufkriterium geworden. ONVIF hat angekündigt, die Unterstützung für Profile S zu beenden und Profile T als Nachfolger zu empfehlen: «The June 2026 version of the ONVIF conformance test tools […] will be the last test tool version that enables manufacturers to claim product conformance to Profile S.» Grund ist die Authentifizierung per Username Token, die «no longer consistent with current cybersecurity recommendations» sei. Bereits installierte Geräte funktionieren weiter, neu gekauft wird ab jetzt aber sinnvollerweise Profile T.

Das ist unangenehm konkret: TP-Link hält in seinen FAQ fest, dass Tapo-Kameras ausschliesslich Profile S unterstützen. Wer heute eine Tapo kauft, kauft ein auslaufendes Profil. Funktionieren wird sie trotzdem — nur landet ihr auf der Seite, die ONVIF gerade verlässt.

Die Fallgruben, die am Produktdatenblatt nicht auffallen

Die folgenden fünf Punkte stehen selten auf der Verpackung und oft nicht einmal auf der Produktseite — sondern in Support-Artikeln, die ihr erfahrungsgemäss erst findet, wenn die Kamera schon an der Wand hängt.

Akkukameras: kein RTSP, und das ist kein Firmware-Versehen

Das ist die teuerste Falle. Akkubetriebene Kameras sind bequem, weil sie kein Kabel brauchen — und sie sind fast durchgehend für den lokalen Betrieb unbrauchbar. Reolink formuliert das für die eigenen Modelle unmissverständlich: Im Alleinbetrieb unterstützt eine Akkukamera «RTSP, RTMP, ONVIF and related communication protocols» nicht. Genannt werden zwei Gründe: Hardware-Grenzen und Energieverwaltung — Fremdsoftware kenne den Standby-Modus der Kamera nicht und würde den Akku leerziehen.

Bei TP-Link steht dasselbe: Für die akkubetriebenen Tapo-Modelle C425, C460, C660, C645D und D230 wird RTSP «generally not supported». Drei Ausnahmen gibt es — D235, D225 und TD25 —, aber nur «when hardwired for power, with a jumper cable installed, and with always-on mode enabled». Also nur dann, wenn ihr den Akkubetrieb aufgebt und ein Kabel legt. Wer ein Kabel legen kann, kauft besser gleich eine Kamera, die dafür gebaut ist.

4G-Kameras: weder RTSP noch ONVIF

Kameras mit eigener SIM-Karte für Orte ohne Netzwerk sind technisch reizvoll und praktisch gesperrt. Reolink führt die 4G-LTE-Modelle — Go-Serie, TrackMix LTE, Duo 2 LTE — schlicht als nicht unterstützt. Das ist kein Zufall: Eine Kamera hinter Carrier-Grade NAT ist von aussen ohnehin nicht direkt erreichbar, der Hersteller-Relay ist dort die Geschäftsgrundlage. Plant eine 4G-Kamera deshalb nie als Teil eures lokalen Systems ein, sondern als eigenständiges, herstellerabhängiges Gerät — oder legt Netz hin.

Kameras, die ohne Hersteller-Hub nichts können

Die dritte Kategorie ist die heimtückischste, weil auf der Produktseite tatsächlich «RTSP» und «ONVIF» steht. Nur eben mit einer Fussnote. Reolinks Akku-WLAN-Kameras — Argus-Serie, Altas-Serie, Battery Doorbell — bekommen die Protokolle laut Hersteller erst über eine «Verbindung zu Reolink Home Hub». Dasselbe gilt für NVR-Kit-Kameras ohne eigene UID, die einen Reolink-NVR verlangen.

Das ist keine offene Schnittstelle, sondern eine verschobene Abhängigkeit: Statt am Cloud-Konto hängt ihr am Hub — einem Gerät, das der Hersteller mit Firmware versorgt, das ausfallen kann und für das es keinen Nachbau gibt.

Cloud-only: Ring und Nest sind keine Kandidaten

Bei den grossen Plattformmarken ist die Lage eindeutig, und sie ist es ohne Fussnote. Googles Support-Seite zum Videoverlauf der Nest-Kameras kennt nur Cloud-Speicherung: ohne Abo bis zu drei Stunden Ereignisvorschau, mit Abo 30 oder 60 Tage Ereignisverlauf und bis zu zehn Tage Dauervideo — «All video history is deleted on a rolling basis». Lokale Speicherung kommt auf der Seite schlicht nicht vor. Bei Ring ist es dasselbe Modell.

Ihr könnt das kaufen, solange ihr wisst, was ihr kauft: einen Dienst mit beigelegter Hardware. Nur ist es dann keine Überwachungskamera ohne Cloud, sondern das genaue Gegenteil, und die Speicherdauer eures eigenen Wohnzimmers steht in einer Preisliste.

Die stille Beschränkung: nur zwei von drei Wegen gleichzeitig

Und dann gibt es Grenzen, die nirgends in der Produktbeschreibung stehen. TP-Link hält in derselben FAQ fest: «Only two of these three options can run at once: Tapo Care, SD card recording, and NVR/NAS/ONVIF software.» Wer also gleichzeitig auf SD-Karte aufzeichnen und auf ein NAS streamen will, hat damit schon beide Plätze belegt. Solche Beschränkungen findet ihr nur, wenn ihr vor dem Kauf gezielt in der Support-Datenbank des Herstellers nach «RTSP» und «ONVIF» sucht — nicht auf der Produktseite.

PoE oder WLAN: die Entscheidung, die ihr nicht rückgängig macht

Power over Ethernet bedeutet, dass Strom und Daten über dasselbe Netzwerkkabel laufen. Ein Kabel, ein Loch in der Wand, kein Netzteil an der Fassade. Für eine fest montierte Aussenkamera ist das fast immer die richtige Wahl.

Bei der Leistung reicht für gewöhnliche Fixkameras der ursprüngliche Standard. Cisco nennt in seiner PoE-Dokumentation 15,4 Watt pro Port für IEEE 802.3af und hält für den Nachfolger fest: «The PoE+ standard increases the maximum power that can be drawn by a powered device from 15.4 W per port to 30 W per port.» Für Schwenk-Neige-Modelle, beheizte Gehäuse oder starke Infrarotstrahler braucht ihr also 802.3at; das noch stärkere IEEE 802.3bt von 2018 ist für Kameras selten nötig.

WLAN-Kameras haben zwei Nachteile, die im Laden nicht auffallen. Der erste ist Zuverlässigkeit: Das Frigate-Projekt schreibt in seinen Hardware-Empfehlungen ungewöhnlich deutlich, «WiFi cameras are not recommended as their streams are less reliable and cause connection loss and/or lost video data». Der zweite ist Störbarkeit: Ein Funknetz lässt sich mit einfachsten Mitteln zumachen, ein Kabel nicht. Für eine Kamera, die genau dann funktionieren soll, wenn jemand nicht will, dass sie funktioniert, ist das kein Nebenaspekt.

Unabhängig vom Übertragungsweg gehört die Kamera in ein eigenes Netzsegment ohne Internetzugang. Wie ihr das aufteilt, steht in Was ist ein VLAN — Anwendung und Beispiele, das die Trennung von Überwachungstechnik und Arbeitsgeräten als eigenes Beispiel durchspielt. Ergänzend regelt eine Firewall, was aus diesem Segment heraus darf — bei einer Kamera: nichts ausser dem Weg zum Aufnahmesystem.

Wohin die Aufnahmen wandern: SD-Karte, NAS oder NVR

Die SD-Karte in der Kamera ist der schlechteste der drei Wege, aus einem Grund, der nichts mit Technik zu tun hat: Sie sitzt im Gerät, das gestohlen oder zerstört wird. Als Zwischenpuffer bei Netzausfall ist sie sinnvoll, als einziger Speicherort nicht.

Der zweite Punkt ist die Dauerschreiblast. Videoaufzeichnung schreibt rund um die Uhr, und normale Desktop-Platten sind dafür nicht ausgelegt. Western Digital gibt für die Überwachungsserie WD Purple im Datenblatt 180 TB jährliche Schreiblast, eine MTBF von einer Million Stunden und bis zu 64 HD-Kameras je Laufwerk an; Seagate hat mit SkyHawk ein Gegenstück. Der Aufpreis ist gering, der Unterschied in der Lebensdauer nicht.

Eine SSD braucht es dafür nicht. Warum sich das bei einem NAS ohnehin meist am Netzwerk erledigt, haben wir in SSD in einer NAS sinnvoll? durchgerechnet — bei Videoaufzeichnung kommt hinzu, dass Dauerschreiben Flash-Speicher am schnellsten altern lässt. Und egal wo die Aufnahmen liegen: Sie ersetzen keine Sicherung, siehe Was ist ein gutes BackUp.

Auflösung, Codec und Nachtsicht: was im Datenblatt zählt

H.264 oder H.265 ist eine Kompatibilitätsfrage

H.265 halbiert grob die Datenmenge gegenüber H.264 — was bei Dauerbetrieb echtes Geld an Speicher spart. Der Haken liegt bei der Software. Frigate empfiehlt in den Hardware-Hinweisen ausdrücklich H.264: «Cameras that output H.264 video and AAC audio will offer the most compatibility with all features of Frigate and Home Assistant.» Auch Browser-Wiedergabe und ältere NAS-Software tun sich mit H.265 schwerer.

Die Lösung heisst Substreams. Eine brauchbare Kamera liefert mehrere Streams gleichzeitig in unterschiedlicher Auflösung und Bildrate — Frigate nennt das als Kriterium: «It is also helpful if your camera supports multiple substreams to allow different resolutions to be used for detection, streaming, and recordings without re-encoding.» Damit zeichnet ihr in H.265 gross auf und lasst die Bewegungserkennung auf dem kleinen H.264-Stream laufen, ohne dass irgendwo umkodiert werden muss. Achtet im Datenblatt also nicht nur auf den Codec, sondern auf die Anzahl konfigurierbarer Streams.

Auflösung: mehr Pixel sind nicht mehr Erkennung

Was zählt, ist nicht die Megapixelzahl, sondern wie viele Pixel auf dem Gesicht oder dem Nummernschild landen — und das hängt an Brennweite und Montageabstand, nicht am Sensor. Eine 4K-Weitwinkelkamera über einem 15 Meter langen Vorplatz liefert weniger verwertbare Details als eine 4-Megapixel-Kamera mit engerem Bildwinkel auf denselben Bereich. Plant deshalb erst den Ausschnitt, dann das Modell — und rechnet die Datenmenge mit.

Nachtsicht: Infrarot, Weisslicht oder lichtstarker Sensor

Drei Bauarten mit drei verschiedenen Zwecken. Klassisches Infrarot liefert ein Schwarzweissbild und fällt niemandem auf — gut für unauffällige Überwachung, schlecht für Farbmerkmale. Weisslicht-Scheinwerfer liefern Farbe und wirken abschreckend, blenden aber die Nachbarschaft. Lichtstarke Sensoren mit grosser Blende liefern Farbe bei Restlicht ohne eigene Beleuchtung, brauchen dafür Strassenlaternen oder Ähnliches. Prüft im Datenblatt, ob sich die Beleuchtung abschalten lässt — bei manchen Modellen bleibt das Weisslicht im Ereignisfall zwangsweise an.

IP-Schutzklasse: was IP66 wirklich verspricht

Die zweistellige Zahl hinter «IP» ist in IEC 60529 «Degrees of protection provided by enclosures (IP Code)» genormt. Die erste Ziffer steht für Fremdkörper und Staub, die zweite für Wasser. Für Aussenkameras heisst das praktisch: IP65 ist strahlwassergeschützt und reicht für eine geschützte Lage unter einem Vordach, IP66 hält starken Strahl aus und ist die vernünftige Untergrenze für freie Montage, IP67 überlebt zusätzlich zeitweiliges Untertauchen.

Zwei Dinge verspricht die Norm nicht. Erstens sagt sie nichts über Temperaturbereiche — dafür steht eine eigene Angabe im Datenblatt, und in höheren Lagen ist sie relevant. Zweitens gilt der Schutzgrad für das Gehäuse, nicht für die Kabelverbindung: Der RJ45-Stecker am Kameraende ist der wunde Punkt und gehört in eine Verbindungsmuffe oder Abzweigdose.

Modellklassen statt Bestenliste

Konkrete Modelle veralten schneller, als ein Artikel gepflegt werden kann — Klassen nicht. Ordnet jedes Gerät, das euch interessiert, in eine dieser vier ein.

• Klasse A — PoE-Fixkamera mit eigenständigem RTSP und ONVIF. Der Regelfall für alles, wo ein Kabel hingeht. Beispiele: Reolinks RLC-Serie und die Professional-Reihe, die der Hersteller als eigenständig unterstützt führt, dazu Dahua und Hikvision samt ihrer OEM-Varianten und am oberen Ende Axis. Prüft trotzdem die ONVIF-Datenbank.
• Klasse B — WLAN-Kamera am Netzteil mit RTSP. Brauchbar, wenn kein Kabel möglich ist. Beispiele: kabelgebundene Tapo-Modelle, Reolink E1 Outdoor, Duo-Serie. Einschränkung: nur ONVIF Profile S, plus die Zwei-von-drei-Regel bei Tapo.
• Klasse C — Akkukamera, die den Hersteller-Hub braucht. Funktioniert lokal, aber nur mit zusätzlicher Hardware desselben Anbieters. Vertretbar an Stellen, wo wirklich kein Strom hingeht — nie als Grundgerüst der Anlage.
• Klasse D — Cloud-only. Ring, Nest, reine 4G-Kameras, Akkumodelle ohne jede Schnittstelle. Kein Kandidat für eine Überwachungskamera ohne Cloud, egal wie gut die Bildqualität ist.

Die Schweizer Rechtslage: was ihr filmen dürft und was nicht

Eine Kamera zu besitzen ist harmlos, sie falsch auszurichten nicht. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte ist unmissverständlich: Privatpersonen dürfen den öffentlichen Raum grundsätzlich nicht überwachen. Die Begründung sitzt: Sicherheit und Ordnung im öffentlichen Raum seien nicht Sache von Privatpersonen, sondern Aufgabe der Polizei. Ausnahmen gibt es nur am Rand — geringfügig mitlaufender öffentlicher Boden bei berechtigter Überwachung des eigenen Grundstücks, oder eine Türsprechanlage mit kleinem Bildwinkel, die nur beim Klingeln aktiv ist.

Praktisch heisst das: Trottoir, Strasse und Parkplatz gehören nicht ins Bild. Prüft den Ausschnitt und blendet aus, was nicht auf euer Grundstück gehört — die meisten Kameras können Bereiche dauerhaft maskieren, und das ist die richtige Stelle dafür.

Für die Nachbarschaft gilt laut EDÖB: Eine Kamera zu Sicherheitszwecken ist zulässig, wenn ein überwiegendes privates Interesse besteht und die Bearbeitungsgrundsätze eingehalten werden. Bei gemeinsam genutzten Bereichen wie Garage oder Waschküche müssen alle Betroffenen vorher konsultiert werden. Und wenn Nachbarn zwangsläufig ins Bild geraten, weil die Kamera nicht anders platziert werden kann, sind sie vorab zu informieren. Genannte Rechtsgrundlagen sind das Datenschutzgesetz — insbesondere das Auskunftsrecht nach Art. 25 DSG — sowie Art. 28 ZGB zum Persönlichkeitsschutz.

Beim Ton wird es strafrechtlich. Der EDÖB verweist auf Art. 179^bis und 179^ter StGB für die Aufnahme nichtöffentlicher Gespräche und auf Art. 179^quater StGB für Aufnahmen aus dem Geheimbereich. Die Konsequenz ist einfach: Schaltet das Mikrofon ab, wenn ihr es nicht wirklich braucht. Fast jede ONVIF-Kamera lässt sich mit reinem Videostream betreiben.

Das ist eine Einordnung, keine Rechtsberatung — bei einem konkreten Streit mit Nachbarn oder Mietern gehört der Fall zu jemandem mit Anwaltspatent.

Was ihr tun könnt: der Prüfplan vor dem Kauf

Neun Schritte, in dieser Reihenfolge. Wer sie durchgeht, kauft keine Kamera zweimal.

• Bildausschnitt zuerst. Legt fest, welche Fläche das Bild zeigen soll und aus welchem Abstand. Daraus ergeben sich Brennweite und Anzahl Kameras — nicht umgekehrt.
• Modell in der ONVIF-Datenbank suchen. Nicht gelistet heisst: unbelegt. Gelistet heisst: ihr wisst auch, welches Profil.
• In der Support-Datenbank des Herstellers nach «RTSP» und «ONVIF» suchen, nicht auf der Produktseite. Dort stehen die Fussnoten — Hub-Pflicht, Akku-Ausschluss, Zwei-von-drei-Regeln.
• Die Wortfolge «eigenständig» prüfen. Steht in der Antwort «requires connection to», «with Home Hub» oder «when connected to NVR», ist die Kamera Klasse C, nicht Klasse A.
• Profile T bevorzugen. Profile S funktioniert weiter, läuft aber aus.
• Anzahl der Substreams prüfen und ob Auflösung und Bildrate je Stream getrennt einstellbar sind.
• PoE nach 802.3af oder 802.3at? Gegen das Leistungsbudget eures Switches rechnen, nicht nur gegen die Portzahl.
• Speicherziel und Platte festlegen, bevor die Kamera bestellt ist. Überwachungsplatte statt Desktop-Platte, und bei einem NAS die Lizenzfrage klären.
• Nach dem Kauf sofort testen: Kamera ins eigene Netzsegment, Internetzugang sperren, RTSP-URL in VLC öffnen. Läuft das Bild, funktioniert die Kamera ohne Hersteller. Läuft es nicht, geht das Gerät innerhalb der Rückgabefrist zurück.

Für den Zugriff von unterwegs gilt: ein Wireguard-VPN ins eigene Netz statt einer Portweiterleitung auf die Kamera. Die Edimax-Advisory ist genau der Grund: Eine Kamera mit ungepatchter Befehlsinjektion, die aus dem Internet erreichbar ist, ist kein Sicherheitsgerät mehr, sondern ein Botnetz-Knoten in eurem Wohnzimmer.

Fazit: Ohne RTSP und ONVIF kauft ihr ein Abo, keine Kamera

Der Markt hat gelernt, dass «ohne Cloud» und «ohne Abo» sich verkaufen, und liefert das Etikett inzwischen zuverlässiger als die Sache. SD-Karte im Gehäuse, App vom Hersteller, Server dazwischen — diese Auslegung erfüllt jedes Werbeversprechen, ohne euch die Kontrolle zu geben.

Die Trennlinie verläuft nicht zwischen Marken, sondern zwischen Bauarten. Eine PoE-Kamera mit eigenständigem RTSP und ONVIF Profile T gehört euch: Sie läuft in einem Netzsegment ohne Internetzugang, sie schreibt auf eure Platte, und sie funktioniert weiter, wenn der Hersteller morgen die Sparte verkauft. Eine Akkukamera mit Hub-Pflicht gehört zu einem Ökosystem. Und eine Cloud-only-Kamera ist überhaupt keine Kamera, sondern ein Speicherabo, dem eine Linse beiliegt.

Diese Entscheidung fällt vor dem Kauf, in einer Support-Datenbank, in fünf Minuten. Danach fällt sie gar nicht mehr.

Quellen und weiterführende Links

• RFC 2326 — Real Time Streaming Protocol (RTSP), IETF, April 1998
• ONVIF — Profile T
• ONVIF — ONVIF to End Support for Profile S; Recommends Profile T as Replacement
• ONVIF — Datenbank der konformen Produkte
• Reolink Support — Which Reolink Products Support CGI/RTSP/ONVIF
• Reolink Support — Can Reolink Battery-Powered Cameras Work with 3rd-Party Software?
• TP-Link — Tapo Camera ONVIF and RTSP Common Questions
• TP-Link — How to View Tapo Camera on PC, NAS, or NVR Using RTSP/ONVIF
• Google Nest Hilfe — Learn about event and 24/7 video history
• CISA — ICS Advisory ICSA-25-063-08, Edimax IC-7100 IP Camera (CVE-2025-1316)
• IEEE 802.3bt-2018 — Power over Ethernet over 4 pairs
• Cisco — Configuring Power over Ethernet (Catalyst 9300)
• IEC 60529 — Degrees of protection provided by enclosures (IP Code)
• Western Digital — WD Purple Surveillance HDD, Datenblatt
• Synology — Lizenzpaket für Überwachungsgeräte
• Frigate — Hardware- und Kameraempfehlungen
• EDÖB — Videoüberwachung des öffentlichen Raums durch Privatpersonen
• EDÖB — Videoüberwachung in der Nachbarschaft

The post Überwachungskamera ohne Cloud: Kaufratgeber 2026 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was am 8. August wirklich passiert ist

Der letzte gemeinsame Block beider Ketten war 961.631. Bei Höhe 961.632 begann das Fenster, in dem BIP-110 von jedem Block eine Signalisierung auf Bit 4 verlangt. Blöcke ohne dieses Signal gelten für eine BIP-110-Node ab da als ungültig.

Die Hauptkette lieferte ihren Block 961.632 am 8. August um 19:35:55 UTC, gefunden von AntPool, mit 5.612 Transaktionen und einer Netzwerk-Difficulty von rund 127,5 Billionen. Das lässt sich in jedem Explorer nachsehen, etwa bei mempool.space. Dieser Block signalisierte nicht — die BIP-110-Nodes verwarfen ihn und blieben stehen, bis ein eigener Miner einen eigenen Block 961.632 fand. Ab diesem Moment gab es zwei Ketten.

Wie knapp die Sache war, sagt die Zahl, die BIP-Editor Mark Erhardt am 9. August auf der Entwickler-Mailingliste nannte: BIP-110 kam auf „just shy of 2.5% of blocks signaling readiness". Nötig gewesen wären 55 Prozent, also 1.109 von 2.016 Blöcken. Was ein Soft Fork und was ein Hard Fork ist und warum der Unterschied hier zählt, steht in Unterschied zwischen Hardfork und Softfork in der Blockchain.

Ein Detail, das in der Berichterstattung untergeht: 961.632 ist durch 2.016 teilbar — 2.016 mal 477 ergibt exakt diese Höhe. Die Abspaltung fiel also punktgenau auf eine Difficulty-Anpassung. Das war kein Zufall, sondern gewollt, und es hat für die Abspaltung die denkbar schlechteste Folge.

Die Difficulty-Falle: 2.016 Blöcke bis zur Anpassung

Eine abgespaltene Kette erbt die Schwierigkeit der Kette, von der sie sich trennt — hier also die vollen 127,5 Billionen, aufgestellt für ein Netz mit hunderten Exahash. Angepasst wird erst nach 2.016 eigenen Blöcken. Weil der Split exakt auf der Anpassungsgrenze lag, muss die BIP-110-Kette diese 2.016 Blöcke vollständig durchziehen, bevor ihre Difficulty auch nur ein einziges Mal fällt. Wer wissen will, wie diese Mechanik funktioniert: Was ist die Mining Difficulty.

Nach Angaben von Bitcoin.com stand die Abspaltung am 15. August bei Block 961.635, also vier Blöcken in sieben Tagen, gefunden vom Pool Roughnecks. Diese Zahl liess sich nicht gegen einen neutralen Explorer prüfen und ist als Medienangabe zu lesen. Rechnet sie trotzdem einmal durch: Bei vier Blöcken pro Woche braucht die Kette für 2.016 Blöcke rund 3.500 Tage — knapp zehn Jahre bis zur ersten Anpassung. Die kursierenden Schätzungen reichen von 350 Tagen bis 25 Jahren, je nach unterstellter Hashrate; die beobachtete Blockrate liegt am pessimistischen Ende.

Das ist kein Anlaufproblem, das sich mit Geduld löst, sondern ein Zustand, in dem eine Kette technisch existiert und wirtschaftlich nicht stattfindet — mit Folgen für jeden, der noch auf ihr sendet.

Ocean schickte 18 Stunden Hashrate auf die tote Kette

Der Mining-Pool Ocean räumte ein, dass ein Konfigurationsfehler Miner rund 18 Stunden lang auf der BIP-110-Kette arbeiten liess, obwohl diese den Endpunkt für die andere Kette gewählt hatten. Der Pool kündigte auf X rund 0,3 BTC Entschädigung an, auszuzahlen binnen 72 Stunden.

Als Lehrstück ist der Vorfall mehr wert als die Summe, denn er zeigt, wer bei einer Kettenspaltung tatsächlich entscheidet: nicht der Miner, sondern derjenige, der die Arbeitsaufträge verteilt — dasselbe Machtgefälle, das wir in Stratum V2 und die Coinbase-Hoheit beschrieben haben.

Der Plan: Proof of Work wechseln und die Miner feuern

Statt das Ergebnis anzunehmen, kündigten die Befürworter einen Ausweg an. Luke Dashjr, langjähriger Bitcoin-Entwickler und Mitautor auf der BIP-110-Seite, schrieb bereits am 5. August auf X: „If BIP110 doesn't pan out, the only option is a PoW change."

Ein Wechsel des Proof-of-Work-Algorithmus macht jeden vorhandenen Bitcoin-ASIC auf dieser Kette wertlos. Die Geräte rechnen SHA-256d in Hardware und können nichts anderes. Das ist kein Nebeneffekt, das ist der Zweck: Wer die Miner nicht überzeugen kann, schliesst sie aus.

„Bpedo": Wer hier wen angegriffen haben soll

Bemerkenswert ist, wie die Vorgänge seither beschrieben werden. Noch am Abend des 8. August schrieb Dashjr auf seinem X-Konto: „. @AntPoolofficial appears to be attacking Bitcoin. Hold tight everyone." Gemeint war der Pool, der wenige Stunden zuvor den regulären Block 961.632 gefunden hatte.

Am 12. August legte er unter der Überschrift „Facts" nach. Vier Punkte, sinngemäss: Am Samstag hätten „bad actors" einen strittigen Hard Fork versucht, „with the purpose of forcing users to distribute CSAM"; daraus sei eine neue „scamcoin with an airdrop" entstanden, die er „Bpedo" nennt. Die ehemaligen Bitcoin-Pools würden das Netzwerk angreifen, „to try to deceive the world into thinking Bpedo is 'the real Bitcoin'". Wer keine eigene Node betreibe, falle darauf herein; ein Upgrade auf „the latest release of Bitcoin Knots" bringe einen zurück „on the Bitcoin network". Und: „Community-led mitigations are in progress to overcome the ongoing attack" — erwartet zum 1. September.

Nüchtern betrachtet steht hier die Realität auf dem Kopf. Die Kette mit 97,5 Prozent der Hashrate hat keine Regel geändert — sie läuft unverändert weiter. Geändert hätte die Regeln der Vorschlag, der die nötige Zustimmung nicht bekam. Wer nichts tut, forkt nicht. Auch der CSAM-Vorwurf trägt die Last nicht, die ihm aufgeladen wird: Dahinter steht die seit Jahren bekannte Tatsache, dass sich beliebige Daten in Transaktionen einbetten lassen — ein Problem, das mit dem gescheiterten Fork weder entstanden noch verschwunden ist, und das kein Miner „erzwingt".

Die Zuspitzung hat einen praktischen Zweck: Wenn die Mehrheitskette ein Betrug ist, ist der Wechsel des Proof of Work keine Abspaltung mehr, sondern Notwehr.

BLAKE2b, ausgewürfelt auf Testnet4

Wie der neue Algorithmus bestimmt wurde, kündigte Dashjr am 11. August auf X im Detail an. Ab 14:00 UTC werde die Testnet4-Kette beobachtet. Dann: „The very next block found, look at the block hash. The last character will choose the new algorithm." Aus einer zuvor zusammengestellten, nach Eignung gewichteten Kandidatenliste sollte also das letzte Zeichen eines Testnetz-Blockhashes auswählen — ein Hexadezimalzeichen, sechzehn Möglichkeiten. Um Manipulation auszuschliessen, veröffentlichte er vorab den SHA256-Hash der Zuordnungstabelle: „You can prove I didn't rig it".

Einen Tag später stand das Ergebnis fest: BLAKE2b, mit einem geplanten Hard Fork zum 1. September 2026. Begründet wird die Wahl damit, dass BLAKE2b auf gewöhnlichen CPUs und GPUs laufe und die ASIC-Dominanz breche.

Die Vorab-Festlegung per Hash ist sauber gemacht, das sei ausdrücklich gesagt: Sie beweist, dass die Tabelle nachträglich nicht verändert wurde. Über die Frage, die zählt, beweist sie nichts. Denn welcher Hash-Algorithmus die Sicherheit eines Netzwerks im Milliardenbereich trägt, gehört in eine mehrjährige Prüfung mit Kryptografen, Referenzimplementierungen, Testnetzen und veröffentlichten Angriffsmodellen — nicht in ein Verfahren, dessen Ergebnis am letzten Zeichen eines Testnetz-Blockhashes hängt. Grosse Sorgfalt lag darauf, dass die Ziehung fair ist, und keine erkennbare darauf, ob überhaupt gezogen werden sollte. Manipulationssicher ausgewürfelt bleibt ausgewürfelt.

Wer Proof of Work tauscht, hat aufgehört, Bitcoin zu sein

Das eigentliche Problem liegt tiefer als die Frage, ob BLAKE2b ein guter Algorithmus ist. Bitcoins Sicherheit besteht nicht aus Regeln in einem Dokument, sondern aus über sechzehn Jahren aufgehäufter Rechenarbeit in SHA-256d. Diese Arbeit ist der Grund, warum sich die Kette nicht umschreiben lässt.

Ein Algorithmuswechsel setzt genau diesen Zähler auf null. Ab dem ersten BLAKE2b-Block sichert eine Kette, die eine sechzehnjährige Transaktionshistorie mit sich trägt, sich selbst mit der Rechenleistung eines Hobbynetzwerks. Wer sie umschreiben will, braucht dann keine Milliarden an Hardware mehr, sondern eine Handvoll Server. Die Befürworter wollen Bitcoin vor einem Angriff schützen und bauen dabei genau die Bedingung her, gegen die Proof of Work überhaupt schützt.

Der Streit um die BIP-Editoren

Parallel läuft ein zweiter Konflikt. Jon Atack beantragte am 9. August auf der Entwickler-Mailingliste, den Status von BIP-110 von „Deployed" auf „Closed" zu setzen, weil das Netzwerk den Fork abgelehnt habe. Widerspruch kam unter anderem von Greg Tonoski, der auf rund 18.000 Nodes verwies, die BIP-110 akzeptieren, und fragte, ob deren Guthaben damit zur Beschlagnahmung freigegeben sei. Sjors Provoost hielt dagegen, dass ein geschlossener BIP-Status niemandem etwas wegnimmt.

Am selben Tag beantragte Mark Erhardt in Pull Request 2248 die Abberufung von Luke Dashjr als BIP-Editor. Die Begründung nennt Interessenkonflikte bei einem Vorschlag, an dem er selbst beteiligt war, weniger als ein Prozent der Editor-Kommentare seit April 2024 und die vorzeitige Vergabe einer BIP-Nummer auf X, bevor der Vorschlag auf der Mailingliste diskutiert war. Die zugehörige Debatte steht in der Mailingliste.

Vollzogen wurde die Abberufung schnell. Bryan Bishop hielt am 10. August auf der Mailingliste fest: „The individual known as Luke Dashjr is no longer an authorized user in the BIP content repository." Damit ist der Schreibzugriff weg — die Rolle also faktisch beendet, keine 26 Stunden nach dem Antrag.

Formal hinkt die Dokumentation nach: Pull Request 2248 war am 17. August unverändert offen, und BIP 3, das die Zuständigen auflistet, führte ihn weiterhin auf. Wer die Lage prüfen will, schaut in beide Dokumente statt auf Schlagzeilen — die einen melden die Entfernung als abgeschlossen, die anderen zeigen sie noch nicht.

Was ihr tun könnt

Das Signalisierungsfenster ist vorbei, der angekündigte Hard Fork zum 1. September ist es nicht. Für die kommenden zwei Wochen gilt deshalb dasselbe wie im August:

• Prüft, welche Software eure Node fährt. Bitcoin Core und Bitcoin Knots vor der RDTS-Erweiterung sind konsensidentisch und folgen derselben Kette; die Unterschiede liegen in der Weiterleitungspolitik. Was das konkret heisst, steht in Bitcoin Knots vs. Bitcoin Core.
• Betreibt ihr Lightning-Kanäle, behaltet den 1. September im Auge. Ein offener Kanal über eine Kettenspaltung hinweg ist eine doppelte Haftung, weil der Gegenpart widerrufene Zustände auf der Kette veröffentlichen kann, die ihr nicht überwacht.
• Wenn ihr mint, klärt vorher, welche Kette euer Pool bedient und ob ihr das selbst umstellen könnt. Der Ocean-Vorfall zeigt, dass die Voreinstellung im Zweifel gegen euch läuft. Wer die Kettenwahl nicht abgeben will, betreibt Solo-Mining — etwa über blitzpool.yourdevice.ch oder einen anderen Solo-Pool, bei dem ihr die Node hinter dem Pool kennt.
• Verlasst euch bei einer Spaltung nicht auf eine Börse: Ob ihr auf einer, beiden oder keiner Kette gutgeschrieben werdet, entscheidet der Verwahrer nachträglich. Eigene Verwahrung und eine eigene Full Node sind der Unterschied zwischen Mitreden und Abwarten.

Wenn eure Node auf der Abspaltung hängt

Wer eine Knots-Version mit den RDTS-Regeln fährt, sieht die Hauptkette gar nicht: Die Node hat deren Block 961.632 als ungültig markiert und bleibt auf 961.631 stehen. Wer in diesem Zustand eine Transaktion gesendet hat, wartet womöglich unbegrenzt auf die Bestätigung — auf einer Kette, auf der alle paar Tage ein Block gefunden wird. Der Weg zurück, exemplarisch für eine Linux-Node:

# 1. Node stoppen
bitcoin-cli stop

# 2. Wallet-Verzeichnis sichern, bevor irgendetwas angefasst wird
cp -a ~/.bitcoin/wallets ~/wallets-backup-$(date +%F)

# 3. Binary austauschen: Bitcoin Core installieren oder eine
#    Knots-Version ohne die RDTS-Regeln. Danach Node starten.

# 4. Stand pruefen
bitcoin-cli getblockchaininfo | grep -e '"blocks"' -e bestblockhash

# 5. Haengt die Node weiter auf 961.631, den als ungueltig
#    markierten Hauptketten-Block wieder zulassen:
bitcoin-cli reconsiderblock \
  00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba

# 6. Bleibt sie stehen, den Blockindex neu aufbauen:
bitcoind -reindex-chainstate

Danach gleicht ihr Höhe und bestblockhash mit einem öffentlichen Explorer ab. Stimmen beide überein, seid ihr wieder auf der Kette, auf der der Rest des Netzes rechnet. Transaktionen, die auf der Abspaltung unbestätigt liegen geblieben sind, müsst ihr auf der Hauptkette neu senden.

Gebt eure Seed-Phrase nirgends ein, um Fork-Coins zu holen

Bei jeder Kettenspaltung tauchen Angebote auf, die versprechen, die Coins auf der neuen Kette „freizuschalten": eine Seite, eine App, ein Formular für eure Wiederherstellungsphrase. Tut das unter keinen Umständen, auch nicht, wenn das Angebot aus dem Umfeld des Forks selbst kommt.

Eure Seed-Phrase ist nicht der Schlüssel zu den Fork-Coins. Sie ist der Schlüssel zu allen euren Coins, auf jeder Kette, die aus demselben Ursprung hervorgegangen ist. Wer sie bekommt, räumt euer Guthaben auf der Hauptkette ab — und das ist echtes Geld, während Coins auf einer Kette mit vier Blöcken pro Woche und ohne Börsenanbindung praktisch nichts wert sind. Das Geschäft lautet also: alles riskieren für nichts.

Fazit: BIP-110 ist an der Arithmetik gescheitert, nicht an einer Verschwörung

BIP-110 hatte einen Mechanismus, der bei 55 Prozent Zustimmung greift, und bekam knapp 2,5. Danach braucht es keine Verschwörung mehr, nur eine Division. Die Kette, die daraus entstand, schafft vier Blöcke pro Woche und bräuchte in diesem Tempo ein Jahrzehnt bis zur ersten Difficulty-Anpassung. Das ist keine Unterdrückung durch eine Übermacht, sondern das vorhersehbare Ergebnis eines Plans, der die Hashrate für eine Formsache hielt.

Die Antwort darauf — einen ausgelosten Algorithmus einzuführen und die Mehrheit des Netzes zu Angreifern zu erklären — beendet die Diskussion, statt sie zu gewinnen. Eine Kette mit neuem Proof of Work ist kein gerettetes Bitcoin. Sie ist ein neues Projekt mit einer alten Transaktionshistorie und ohne die Arbeit, die diese Historie bisher geschützt hat. Es steht jedem frei, so etwas zu starten. Nur sollte es dann seinen eigenen Namen tragen.

Für alle anderen hat der August eine beruhigende Nachricht geliefert: Bitcoins Konsensregeln lassen sich nicht per Ankündigung ändern, auch nicht von langjährigen Entwicklern mit lauter Stimme. Das ist genau die Eigenschaft, wegen der sich das Ganze lohnt.

Quellen und weiterführende Links

• BIP-110: Reduced Data Temporary Softfork — Text des Vorschlags mit Aktivierungsparametern
• bitcoindev: BIP 110 – update status to closed — Debatte ab 9. August 2026
• bitcoindev: Motion to remove Luke Dashjr from BIP Editors
• bitcoin/bips Pull Request 2248: process – Remove Luke from BIP Editors
• BIP 3 — Liste der amtierenden BIP-Editoren
• mempool.space: Block 961.632 — Zeitstempel, Miner, Difficulty und Blockhash der Hauptkette
• Luke Dashjr am 5. August 2026 zum möglichen PoW-Wechsel
• Luke Dashjr am 11. August 2026 zum Auswahlverfahren über Testnet4
• Das X-Konto von Luke Dashjr — Fundstelle der Beiträge vom 8. und 12. August 2026 („attacking Bitcoin", „Facts"/„Bpedo")
• Ocean zur Entschädigung nach dem Konfigurationsfehler
• Start9: Navigating the BIP-110 (RDTS) Activation — Hinweise für Node- und Lightning-Betreiber
• bip110.run — Statusanzeige zu Signalisierung und Kettenspitzen
• Bitcoin.com: BIP-110 Breakaway Chain Faces a Long Fight to Survive — Fundstelle für Blockstand und Pool der Abspaltung

The post BIP-110 gescheitert: jetzt soll BLAKE2b es richten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was die Android Entwickler-Verifizierung seit Februar tatsächlich geworden ist

Googles eigener Fahrplan steht seit Juni auf dem Android Developers Blog und in der Entwicklerdokumentation. Er ist bemerkenswert unspektakulär formuliert, und genau das lohnt sich anzusehen.

Im Juni 2026 hat Google einen neuen Systemdienst ausgerollt, den Android Developer Verifier. Er läuft laut Dokumentation auf allen zertifizierten Android-Geräten ab Android 7. Im Juli kamen die Programmierschnittstellen dazu: eine Status-Abfrage für Entwickler-IDs und ein früher Zugang zur Konsolen-Schnittstelle, mit der sich Registrierungen aus einer Build-Pipeline heraus in grosser Zahl anlegen lassen. Im August 2026 — also jetzt — schaltet Google die Limited Distribution Accounts und den sogenannten Advanced Flow weltweit frei. Und am 30. September 2026 wird die Registrierung erstmals erzwungen: in Brasilien, Indonesien, Singapur und Thailand, bei den teilnehmenden Stores. Das sind Google Play, der HONOR App Market, der OPPO App Market, der Samsung Galaxy Store, der Palm Store von Transsion, der V-Appstore von vivo und Xiaomis GetApps. Für 2027 und danach kündigt Google die weltweite Ausdehnung auf alle zertifizierten Android-Geräte an.

Am 30. September passiert weniger, als die Schlagzeilen sagen

Hier lohnt sich Genauigkeit, weil an dieser Stelle viel Unsinn kursiert. Der Stichtag im September beendet das Sideloading nicht. Googles eigene FAQ sagt es klar: Wer seine App über andere Stores verteilt oder wessen Nutzer die App direkt sideloaden, für den gelten die neuen Anforderungen "noch nicht". Das entscheidende Wort ist "noch". Was am 30. September greift, betrifft die oben genannten Stores in vier Ländern.

Wer daraus Entwarnung liest, hat den Aufbau nicht verstanden. Der Verifier ist bereits verteilt. Die Registrierungsschnittstellen sind bereits offen. Die Kontotypen sind bereits definiert. Was 2027 folgt, ist kein neues Projekt, sondern das Umlegen eines Schalters an einem System, das dann seit anderthalb Jahren läuft und eingespielt ist. Der September ist der Feldtest, nicht das Ziel.

Der Advanced Flow ist das eigentliche Druckmittel — und Google sagt nicht, was er verlangt

Für alle, die trotzdem Apps unverifizierter Entwickler installieren wollen, hat Google den Advanced Flow angekündigt. In der offiziellen Hilfeseite steht dazu genau ein Satz: Nutzer könnten die Risiken akzeptieren, indem sie "einen einmaligen Advanced Flow durchlaufen, der aufklärende Sicherheitsschritte enthält". Mehr nicht. Keine Beschreibung der Schritte, keine Angabe zu Wartezeiten, kein Hinweis darauf, ob ein Neustart oder eine erneute Anmeldung nötig ist.

In der Fachpresse kursieren Beschreibungen, wonach der Ablauf das Aktivieren des Entwicklermodus, einen Neustart, eine Wartezeit von 24 Stunden und eine erneute Authentifizierung umfassen soll. Diese Angaben lassen sich in Googles eigener Dokumentation nicht nachprüfen, und deshalb stehen sie hier auch nicht als Tatsache. Bemerkenswert ist etwas anderes: Der Advanced Flow ist laut Googles Zeitplan seit diesem Monat weltweit aktiv, der erste Durchsetzungsstichtag liegt sechs Wochen entfernt — und die Firma beschreibt bis heute nicht öffentlich, was Nutzer konkret tun müssen, um eine App zu installieren, die sie installieren wollen. Ein Unternehmen, das eine Hürde als Sicherheitsgewinn verkauft, dürfte kein Problem damit haben, diese Hürde zu beschreiben.

Das ist kein Detail. Ob eine Nutzerentscheidung zwei Klicks kostet oder einen Tag Wartezeit, entscheidet darüber, ob sie in der Praxis getroffen wird. Wer schon einmal beobachtet hat, wie viele Leute an "Installation aus unbekannten Quellen zulassen" scheitern, weiss, wie wenig Reibung nötig ist, um eine Möglichkeit faktisch abzuschaffen, ohne sie formal zu verbieten.

20 Geräte sind kein Zugeständnis, sondern eine Definition

Auf die Kritik der letzten Monate hat Google mit einer Abstufung reagiert. Es gibt jetzt zwei Kontotypen. Der Full Distribution Account kostet 25 US-Dollar einmalig und verlangt einen amtlichen Ausweis. Der Limited Distribution Account ist kostenlos, verlangt keinen Ausweis — und erlaubt die Verteilung an höchstens 20 Geräte. Google beschreibt ihn als Angebot für "Studenten, Hobbyisten und Lernende". Organisationen brauchen zusätzlich eine D-U-N-S-Nummer von Dun & Bradstreet; die ist gratis, ihre Ausstellung dauert aber bis zu 28 Tage.

Das wurde vielfach als Einlenken gelesen. Es ist das Gegenteil. Mit der 20-Geräte-Grenze definiert Google, wo Hobby aufhört und Verteilung anfängt — und zieht diese Linie so, dass praktisch jedes ernstzunehmende freie Projekt auf der falschen Seite landet. Eine App mit fünfzig Nutzern ist kein Hobby mehr. Der Entwickler eines kleinen Matrix-Clients, einer Wallet-Erweiterung oder eines Werkzeugs für die eigene Community wird nicht deshalb zum kommerziellen Marktteilnehmer, weil hundert Leute das Ding installiert haben. Für Google ist er es ab Gerät einundzwanzig.

Und dann ist da der Ausweis. Für einen Entwickler in Zürich mag das eine Formalität sein. Für jemanden, der ein Umgehungswerkzeug für ein autoritär regiertes Land pflegt, ist es das Ende der Beteiligung. Pseudonymität ist in freier Software kein Schlupfloch, sondern eine Arbeitsbedingung. Genau deshalb funktionieren Signaturprüfungen wie die Verifikation über ASC-Signaturen auch ohne Klarnamen: Sie beantworten die Frage "stammt dieses Paket von derselben Quelle wie das letzte", und nur die ist für Sicherheit relevant.

Der Hebel liegt beim Entwickler, nicht bei eurem Gerät

Damit sind wir beim Kern. Registriert wird nicht euer Telefon, registriert wird das Paket: Package Name und Signaturschlüssel, gebunden an eine verifizierte Identität. Wer Google Play App Signing nutzt, dessen Apps übernimmt Google automatisch in dieses Register. Diese Bindung ist kanalunabhängig. Sie hängt nicht daran, woher die APK-Datei kommt, sondern daran, ob es zu Package Name und Schlüssel einen registrierten Menschen gibt.

Der praktische Effekt: Google muss euer Gerät gar nicht kontrollieren. Es reicht, wenn der Markt der zertifizierten Geräte gross genug ist, dass sich kein Entwickler leisten kann, dort nicht zu erscheinen. Wer sich registriert, um seine App weiter an drei Milliarden Android-Nutzer ausliefern zu können, hat damit dieselbe Identität an dasselbe Register gehängt, das für jeden anderen Kanal gilt. Wer sich weigert, verschwindet aus dem Play Store und behält seine Nische. Beides sind Entscheidungen, die der Entwickler trifft — nicht ihr.

Custom-ROMs bleiben frei, und das ist die schlechtere Nachricht, als sie klingt

Technisch gilt die Verifizierung ausschliesslich für zertifizierte Android-Geräte. Das GrapheneOS-Projekt hat das im eigenen Forum knapp festgehalten: "It's not relevant to GrapheneOS. GrapheneOS does not have Google Mobile Services and rules for Google certified operating systems don't apply to it." Dasselbe gilt für CalyxOS, LineageOS und jeden anderen AOSP-Bau. Auch ADB bleibt ausgenommen; wer per Kabel installiert, ist von alldem nicht betroffen.

Das ist echt und es ist wichtig. Es ist aber kein Schutzraum, sondern eine Auffangvorrichtung. Ein Gerät mit GrapheneOS garantiert euch, dass euch niemand an der Installation hindert. Es garantiert nicht, dass es etwas zu installieren gibt. Wenn der Entwickler eines Werkzeugs, das ihr nutzt, in zwei Jahren entscheidet, dass er seinen Pass nicht bei Google hinterlegt, und deshalb die Android-Version einstellt, dann hilft euch euer offenes Betriebssystem exakt nichts. Ihr habt dann ein Telefon, auf dem ihr alles installieren dürft, und nichts mehr, was ihr installieren wollt.

Das ist der Grund, warum die verbreitete Beruhigung "betrifft uns nicht, wir haben eh ein Custom-ROM" in die Irre führt. Sie verwechselt die Freiheit, etwas zu tun, mit der Existenz dessen, was ihr tun möchtet. Wir haben diesen Mechanismus schon bei Googles Verschärfungen bei den Pixel-Geräten gesehen und in grösserem Zusammenhang bei der Frage, wie die Fassade der Offenheit bei Android bröckelt: Die Sperre kommt nie über das Gerät, sie kommt über das, was um das Gerät herum verschwindet.

Warum F-Droids Warnung diesmal keine Übertreibung ist

F-Droid formuliert seit Herbst 2025 sehr direkt, dass das Projekt in dieser Form nicht überleben würde. Im Originalwortlaut: "the developer registration decree will end the F-Droid project and other free/open-source app distribution sources as we know them today". Das klingt nach Alarmrhetorik, ist aber strukturell begründet. F-Droid baut und signiert Apps selbst — genau der Punkt, den wir in unserem Artikel zu den Sicherheitsbedenken bei F-Droid kritisch beleuchtet haben. Im neuen Modell ist das ein Problem: F-Droid kann Entwickler nicht zwingen, sich bei Google registrieren zu lassen, und kann die Package Names auch nicht selbst beanspruchen, ohne sich Verteilungsrechte anzumassen, die ihm nicht zustehen.

Im Februar 2026 hat F-Droid deshalb zusammen mit der Electronic Frontier Foundation, der Free Software Foundation Europe und der Software Freedom Conservancy einen offenen Brief veröffentlicht, der Entwickler auffordert, sich nicht zu registrieren. Die Kampagne Keep Android Open zählt inzwischen 71 Organisationen aus 23 Ländern, darunter das Tor-Projekt, Nextcloud, KDE, die GNOME Foundation und LineageOS, dazu über 100'000 Unterschriften unter einer Petition. Das ist für Verhältnisse der freien Softwarewelt eine ungewöhnlich breite Front.

Das Kartellurteil vom 2. Juli traf ein Geschäftsmodell, das Google gerade ersetzt

Am 2. Juli 2026 hat der Gerichtshof der Europäischen Union in der Rechtssache C-738/22 P das Rechtsmittel von Google und Alphabet zurückgewiesen und die Geldbusse von rund 4,125 Milliarden Euro bestätigt, davon 1,52 Milliarden gesamtschuldnerisch für Alphabet. Bestraft wurden drei Praktiken: Vorinstallationsbedingungen für Google Search und Chrome als Preis für den Play-Store-Zugang, Umsatzbeteiligungen gegen die Vorinstallation konkurrierender Suchdienste, und Anti-Fragmentierungsvereinbarungen, mit denen sich Hersteller verpflichteten, "keine Geräte zu verkaufen, die mit nicht von Google zugelassenen Versionen des Betriebssystems Android ausgestattet sind".

Acht Jahre hat dieses Verfahren gedauert. Es ging um Verträge: darum, was Google Geräteherstellern vorschreiben durfte. Und während es lief, hat Google den Hebel gewechselt. Die Entwickler-Verifizierung braucht keine Verträge mit Herstellern. Sie braucht einen Systemdienst und ein Register. Die Free Software Foundation Europe hat das Ende Juli auf den Punkt gebracht: Google verlagere seine Kontrolle von Verträgen hin zur Beherrschung von Ökosystem und Interoperabilität. Ein Bussgeld von 4,125 Milliarden Euro ist für Alphabet eine Position in der Quartalsrechnung. Ein Register, das jede Android-App an eine verifizierte Identität bindet, ist ein Strukturvorteil auf Jahrzehnte.

Brüssel hat gefragt und bislang keine Antwort bekommen

Im EU-Parlament liegt die Frage seit Monaten auf dem Tisch. Christel Schaldemose hat am 8. April 2026 eine schriftliche Anfrage an die Kommission gerichtet, die drei Dinge wissen will: ob eine zentrale Registrierungs- und Verifizierungspflicht für alle Android-Entwickler mit dem Digital Markets Act vereinbar ist, ob die Kommission darin eine Einschränkung von Sideloading und Drittanbieter-Stores sieht, und wie sie sicherstellen will, dass Sicherheitsanforderungen nicht zur Umgehung des DMA benutzt werden. Bereits am 9. März 2026 hatten sechs Abgeordnete der Fraktion Renew eine Anfrage zum selben Themenkreis eingereicht. Eine Antwort der Kommission ist zu keiner der beiden veröffentlicht.

Das ist die eigentlich beunruhigende Zahl in diesem Text. Vier Monate für eine Frage, deren Beantwortung darüber entscheidet, ob der wichtigste Hebel der europäischen Plattformregulierung auf den Vorgang überhaupt anwendbar ist — während Google parallel den Systemdienst ausrollt, die Schnittstellen öffnet und einen Stichtag setzt. Regulierung, die langsamer ist als der Rollout, den sie prüfen soll, reguliert nichts.

Die Schweiz hat nicht einmal die Frage

Für Leser in der Schweiz kommt eine unangenehme Ebene dazu: Der Digital Markets Act gilt hier nicht. Es gibt keine Vorschrift, die Google zwingt, in der Schweiz dasselbe anzubieten wie im EWR. Und Google nutzt das nachweislich aus.

Am 14. Juli 2026 hat das Sekretariat der Wettbewerbskommission eine Vorabklärung gegen Google eröffnet. Der Anlass: Google hat den sogenannten Choice Screen bei der Ersteinrichtung von Android-Geräten in der Schweiz abgeschafft — jene Auswahl, mit der Nutzer ihre Standardsuchmaschine selbst bestimmen. In der EU besteht die Auswahl weiter, weil sie dort vorgeschrieben ist. Die WEKO hält fest, der Choice Screen solle "Abschottungseffekte durch Voreinstellungen verringern", und prüft nun, ob die Abschaffung eine unzulässige Wettbewerbsbeschränkung nach Kartellgesetz darstellt.

Das ist ein Lehrstück, und zwar ein aktuelles. Es zeigt in einem konkreten, überprüfbaren Fall, was Google mit einem Markt macht, in dem es nicht muss: Es nimmt die Wahlmöglichkeit weg. Wer glaubt, bei einer künftigen Ausnahmeregelung zur Entwickler-Verifizierung — etwa erzwungen durch den DMA — würde die Schweiz automatisch mitprofitieren, sollte sich diesen Vorgang genau ansehen. Es gibt nichts, das automatisch mitprofitiert. Eine Vorabklärung ist zudem noch keine Untersuchung und erst recht keine Verfügung; sie klärt nur, ob es überhaupt Anhaltspunkte gibt.

Die Gegenposition: Malware auf Android ist ein echtes Problem

Es wäre unredlich, das Sicherheitsargument abzutun. Betrug über sideloadete Apps ist in den vier Startländern kein Hirngespinst, sondern ein Massenphänomen mit realen Opfern. Wer in Indonesien oder Thailand über eine gefälschte Banking-App sein Erspartes verliert, hat wenig Interesse an Prinzipiendebatten über Softwarefreiheit. Googles Zahlen zum Malware-Aufkommen aus nicht überprüften Quellen haben wir im Februar-Artikel bereits eingeordnet und wiederholen sie hier nicht.

Der Einwand trägt trotzdem nicht, und zwar aus einem sehr technischen Grund: Identität ist keine Sicherheitseigenschaft. Ein Ausweis beim Anbieter beantwortet nicht die Frage, ob eine App schädlich ist. Er beantwortet die Frage, wen sich hinterher belangen lässt. Das ist ein legitimes Ziel der Strafverfolgung, aber es ist Betrugsbekämpfung mit den Mitteln der Zugangskontrolle — und es ist genau die Argumentationsfigur, die uns aus der Debatte um Altersverifikation und Klarnamenpflicht bekannt ist. Wer organisierten Betrug betreibt, kauft ein verifiziertes Konto oder benutzt einen gestohlenen Ausweis. Wer eine Kryptowallet für zweihundert Leute pflegt, hat diese Möglichkeit nicht.

Dazu kommt: Der Play Store ist bereits ein verifizierter Kanal, und Schadsoftware taucht dort regelmässig auf. Verifizierung hat das dort nie verhindert. Was Schadsoftware verhindert, sind Berechtigungsmodelle, Sandboxing, reproduzierbare Builds und Signaturketten — technische Massnahmen, an denen sich das Gerät orientieren kann, ohne zu wissen, wie der Entwickler heisst.

Was ihr tun könnt

• Rechnet nicht mit dem 30. September, sondern mit 2027. Wer heute eine App aus einer freien Quelle nutzt, sollte jetzt prüfen, ob es die Anwendung auch als Flatpak, als Web-Anwendung oder auf einem anderen Gerät gibt. Abhängigkeiten aufzulösen dauert länger als ein Wochenende.
• Legt euch ein Archiv eurer APK-Dateien an. Bereits installierte Apps sind von der Verifizierung nicht rückwirkend betroffen — Updates und Neuinstallationen dagegen schon. Eine lokale Kopie der letzten funktionierenden Version ist keine Paranoia, sondern Datensicherung.
• Nutzt Verteilwege, die nicht über einen Store laufen. Obtainium holt Apps direkt aus den Release-Seiten der Projekte. Das löst das Registerproblem nicht, hält aber die Zahl der Zwischenstationen klein und macht sichtbar, woher eine Datei tatsächlich kommt.
• Unterstützt die Entwickler, die ihr nutzt — mit Geld. Die 25 Dollar sind nicht das Problem, die Sichtbarkeitsanforderung ist es. Aber ein Projekt, das seine Nutzer kennt und von ihnen getragen wird, kann eine Grundsatzentscheidung überhaupt treffen. Ein Projekt, das von Play-Store-Reichweite lebt, kann es nicht.
• Schreibt an die Aufsicht, und zwar an die richtige. In der EU ist die zuständige Stelle die DMA-Einheit der Kommission. In der Schweiz ist es die Wettbewerbskommission, die mit der Choice-Screen-Vorabklärung gerade zeigt, dass sie sich für Googles Sonderbehandlung dieses Marktes interessiert. Eine sachliche Eingabe mit konkretem Bezug ist mehr wert als eine Unterschrift. Am Ende des Briefs haben wir euch noch einen Musterbrief geschrieben, welchen ihr die WeKo eures Landes schicken könnt.
• Wechselt das Betriebssystem trotzdem. Ein Custom-ROM löst dieses Problem nicht, aber es löst die anderen. Und es sorgt dafür, dass ihr die Wahl noch habt, wenn es eng wird.

Fazit: Google braucht euer Gerät nicht, es braucht eure Entwickler

Die ganze Debatte um die Android Entwickler-Verifizierung dreht sich um die falsche Frage. Sie fragt, ob euer Telefon euch etwas verbietet. Die Antwort darauf ist beruhigend und irrelevant: Auf einem nicht zertifizierten Gerät verbietet euch niemand etwas, und daran wird sich absehbar nichts ändern.

Die richtige Frage lautet, wer künftig überhaupt noch Android-Software veröffentlichen kann, ohne einen Ausweis bei einem amerikanischen Konzern zu hinterlegen. Registriert wird nicht das Gerät, sondern das Paket. Und ein Register, das Package Name und Signaturschlüssel an eine amtlich geprüfte Identität bindet, wirkt in jedem Kanal, auch in denen, die Google formal gar nicht kontrolliert — weil der Entwickler nur eine Identität hat.

Der Gerichtshof hat acht Jahre gebraucht, um Google für Verträge zu bestrafen, die das Unternehmen inzwischen nicht mehr braucht. Das Parlament fragt seit April und bekommt keine Antwort. Die Schweiz hat nicht einmal das Gesetz, unter dem sich die Frage stellen liesse. Und in sechs Wochen läuft der erste Stichtag ab. Dass Custom-ROMs ausgenommen bleiben, ist unter diesen Umständen kein Sieg, sondern eine Fussnote: Es ist die Erlaubnis, in einem leeren Raum zu stehen und alles installieren zu dürfen, was es dann noch gibt.

Musterbrief an eure Wettbewerkskommission

Wir haben euch einen Musterbrief entworfen, welchen ihr an die jeweilige Kommission eures Landes abschicken könnt. Jeder sollte diese Möglichkeit ergreifen, auch Nutzer, die nicht betroffen sind, und sich für Open Source Software weniger interessieren, denn falls ihr euch später interessiert, sind die Möglichkeiten eingeschränkt.

Betreff: Hinweis auf eine mögliche Wettbewerbsbeschränkung — Registrierungspflicht für Android-Entwickler („Android Developer Verification")

Sehr geehrte Damen und Herren

ich wende mich als [Nutzer von Android-Geräten / Softwareentwickler / Betreiber eines Kleinunternehmens] an Sie und möchte Sie auf eine Massnahme von Google LLC hinweisen, die aus meiner Sicht den Wettbewerb bei der Verteilung von Android-Anwendungen erheblich beeinträchtigen kann.

Sachverhalt

Google führt schrittweise eine Pflicht ein, wonach Entwickler von Android-Anwendungen sich bei Google registrieren und ihre Identität nachweisen müssen, damit ihre Anwendungen auf Android-Geräten installiert werden können. Registriert werden dabei nicht nur die Entwickler selbst, sondern auch die Kennungen ihrer Anwendungen und deren Signaturschlüssel.

Soweit öffentlich dokumentiert, ist der Ablauf folgender: Seit Juni 2026 verteilt Google einen Systemdienst („Android Developer Verifier") auf zertifizierte Android-Geräte ab Android 7. Für die Vollregistrierung sind ein amtlicher Ausweis und eine Gebühr von 25 US-Dollar erforderlich; ein kostenloses Konto ohne Ausweisnachweis erlaubt die Verteilung an höchstens 20 Geräte. Ab dem 30. September 2026 wird die Registrierung in Brasilien, Indonesien, Singapur und Thailand bei den teilnehmenden App-Stores durchgesetzt. Für 2027 kündigt Google die weltweite Ausdehnung auf alle zertifizierten Android-Geräte an.

Der Zeitplan und die Bedingungen sind hier dokumentiert: https://developer.android.com/developer-verification sowie https://developer.android.com/developer-verification/guides/faq

Warum ich das für wettbewerbsrechtlich bedenklich halte

Erstens wirkt die Registrierung kanalunabhängig. Sie hängt nicht daran, über welchen Vertriebsweg eine Anwendung bezogen wird, sondern an der Kennung und dem Signaturschlüssel der Anwendung selbst. Google erlangt damit Kontrolle auch über Vertriebswege, die es nicht betreibt — konkurrierende App-Stores und den direkten Bezug vom Entwickler.

Zweitens erhöht sie die Marktzutrittsschranken für konkurrierende Vertriebsplattformen. Ein alternativer App-Store kann Entwickler nicht dazu bewegen, sich bei einem Wettbewerber registrieren zu lassen, und kann fremde Anwendungskennungen auch nicht selbst beanspruchen. Betreiber solcher Plattformen haben öffentlich erklärt, in dieser Form nicht fortbestehen zu können.

Drittens trifft die Ausweispflicht kleine und unentgeltlich arbeitende Entwickler unverhältnismässig. Wer nicht bereit oder in der Lage ist, einem einzelnen Unternehmen ein Ausweisdokument zu hinterlegen, verliert den Zugang zu einer Nutzerbasis von mehreren Milliarden Geräten.

Viertens überzeugt mich die Sicherheitsbegründung nicht. Eine Identitätsprüfung stellt nicht fest, ob eine Anwendung schädlich ist, sondern nur, wer sie veröffentlicht hat. Mildere und bereits etablierte Mittel — Signaturprüfung, Berechtigungsmodelle, Sandboxing, Prüfung der Anwendung selbst — erreichen das Sicherheitsziel, ohne die Vertriebswege zu verengen. Auch in Googles eigenem App-Store tritt Schadsoftware trotz Registrierung regelmässig auf.

[Für Eingaben innerhalb der EU ergänzen: Nach meinem Verständnis erlaubt Artikel 6 Absatz 4 der Verordnung (EU) 2022/1925 Sicherheitsmassnahmen nur, soweit sie „strictly necessary and proportionate" sind. Ob eine ausnahmslose Identitätsregistrierung diesen Massstab erfüllt, erscheint mir zweifelhaft.]

Meine Betroffenheit

[Beschreibt hier in zwei bis drei Sätzen konkret eure Lage. Beispiele: Ich beziehe die Anwendungen [Name] und [Name] über eine alternative Bezugsquelle, weil sie im Play Store nicht verfügbar sind. / Ich veröffentliche seit [Jahr] die Anwendung [Name] als freie Software und bin nicht bereit, dafür ein Ausweisdokument bei Google zu hinterlegen. / Ich betreibe ein Kleinunternehmen und verteile eine interne Anwendung an [Zahl] Geräte.]

Mein Anliegen

Ich bitte Sie zu prüfen, ob diese Massnahme mit dem in Ihrem Zuständigkeitsbereich geltenden Wettbewerbsrecht vereinbar ist, und gegebenenfalls tätig zu werden, bevor die weltweite Durchsetzung im Jahr 2027 wirksam wird. Eine nachträgliche Beurteilung liefe ins Leere: Sind Entwickler und alternative Vertriebswege einmal abgewandert, lässt sich der Zustand davor nicht wiederherstellen.

Für Rückfragen stehe ich gerne zur Verfügung.

Freundliche Grüsse
[Vorname Name]
[Adresse]
[E-Mail]
[Ort, Datum]

Wohin damit

Anderswo — sucht nach „competition authority" oder „Wettbewerbsbehörde" plus Landesname. Fast jede hat ein Hinweisformular.

Schweiz — Sekretariat der Wettbewerbskommission WEKO, Bern. Anschrift unter weko.admin.ch. Nehmt Bezug auf die Vorabklärung vom 14. Juli 2026, in der das Sekretariat bereits Googles Umgang mit dem Schweizer Markt untersucht — das ist ein sachlicher Anknüpfungspunkt, kein Zufall.

Deutschland — Bundeskartellamt, Bonn. Alphabet/Google unterliegt dort seit dem 30. Dezember 2021 der besonderen Missbrauchsaufsicht nach § 19a GWB. Das könnt ihr im Betreff erwähnen.

Österreich — Bundeswettbewerbsbehörde, es gibt ein eigenes Beschwerdeformular.

EU-weit — zusätzlich die Europäische Kommission über das Kontaktformular für Bürger zum Digital Markets Act. Die Kommission verweist ausdrücklich darauf, dass ihr euch parallel an eure nationale Wettbewerbsbehörde wenden könnt.

Quellen und weiterführende Links

• Android Developers Blog: Android developer verification — Googles Zeitplan von Juni 2026
• developer.android.com: Developer verification — Meilensteine und betroffene Geräte
• developer.android.com: Verification FAQ — Kontotypen, Gebühren, Geltungsbereich
• Google-Hilfe: Apps von verifizierten Entwicklern installieren — die einzige öffentliche Beschreibung des Advanced Flow
• Gerichtshof der EU, Pressemitteilung zum Urteil C-738/22 P vom 2. Juli 2026 (PDF)
• Europäisches Parlament, schriftliche Anfrage E-001419/2026 von Christel Schaldemose
• Europäisches Parlament, schriftliche Anfrage E-000971/2026 zu Beschränkungen der App-Verteilung
• WEKO: Vorabklärung gegen Google zum Choice Screen, 14. Juli 2026
• F-Droid: Offener Brief gegen die Developer Verification
• F-Droid: Google's developer registration decree — die ursprüngliche Einschätzung des Projekts
• Keep Android Open — Kampagne, offener Brief und Unterstützerliste
• FSFE: Google Android antitrust ruling shows the next battle is over who controls trust, 28. Juli 2026
• GrapheneOS-Forum: New Google app developer identification requirements in 2026

The post Android Entwickler-Verifizierung: euer Gerät ist egal appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Unterschied zu einem gewöhnlichen Proxy liegt in der Richtung. Ein normaler Proxy steht vor euch und schützt euch gegenüber dem Server. Ein Reverse Proxy steht vor den Servern und nimmt ihnen die Aussenwelt ab. Für den Browser existiert nur eine einzige Adresse, ein einziges Zertifikat, ein einziger Einstiegspunkt. Was dahinter läuft, auf welchem Port, in welchem Container, auf welchem Rechner im lokalen Netz — davon bekommt der Client nichts mit.

Der naheliegende Gegenvorschlag lautet: einfach jedem Dienst einen eigenen Port geben und die Sache über example.ch:8080 ansprechen. Das funktioniert, bis ihr das erste Mal aus einem fremden WLAN, einem Firmennetz oder einem Hotelnetzwerk zugreifen wollt. Dort ist alles ausser 80 und 443 üblicherweise dicht. Dazu kommt, dass jedes dieser Ziele ein eigenes gültiges Zertifikat braucht und jeder Dienst seine TLS-Konfiguration selbst pflegen müsste — mit dem Ergebnis, dass drei Programme drei verschiedene Meinungen darüber haben, welche Cipher noch in Ordnung sind.

Genau an dieser Stelle setzt dieser Artikel an: eine vollständige Einrichtung von Caddy als Reverse Proxy unter Debian und Ubuntu, von der Installation über die erste Caddyfile bis zu Wildcard-Zertifikaten per DNS-Challenge. Wer bisher mit Apache und Certbot gearbeitet hat, findet den vertrauten Weg in unserer Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver. Hier geht es um den Weg, bei dem dieser Schritt schlicht entfällt.

Warum Caddy und nicht nginx

Caddy ist ein in Go geschriebener Webserver, der unter der Apache-2.0-Lizenz steht und ohne externe Abhängigkeiten auskommt. Die aktuelle stabile Version ist v2.11.4 vom 3. Juni 2026. Das Alleinstellungsmerkmal steht im Untertitel des Projekts und ist keine Marketingfloskel: automatisches HTTPS, und zwar als Standardverhalten, nicht als Zusatzpaket.

Automatisches HTTPS ist eingebaut, nicht angeflanscht

Bei nginx oder Apache läuft die Zertifikatsbeschaffung über ein zweites Programm. Certbot legt Dateien ab, schreibt in die Konfiguration hinein, richtet einen Timer ein und startet den Webserver neu. Vier bewegliche Teile, die alle einzeln kaputtgehen können. Caddy spricht ACME selbst. Es erkennt aus der Konfiguration, für welche Hostnamen es Zertifikate braucht, holt sie, erneuert sie und leitet HTTP auf HTTPS um — ohne dass ihr das irgendwo hinschreibt.

Wie gross der Unterschied im Alltag ist, zeigt das Projekt Immich selbst. In der offiziellen Reverse-Proxy-Dokumentation steht eine nginx-Konfiguration mit erhöhtem Upload-Limit, abgeschaltetem Request-Buffering, gesetzten Weiterleitungs-Headern und Timeouts von 600 Sekunden. Direkt darunter steht die Caddy-Variante, vollständig:

immich.example.org {
    reverse_proxy http://127.0.0.1:2283
}

Das ist kein verkürztes Beispiel. Die drei Dinge, die nginx dort von Hand braucht, sind in Caddy Standard. Das Upload-Limit: nginx begrenzt den Request-Body per Vorgabe auf 1 MB und antwortet darüber mit einem 413, was bei Foto- und Video-Uploads sofort auffällt. Caddy kennt kein solches Vorgabelimit, die Direktive request_body müsst ihr setzen, wenn ihr begrenzen wollt. Die Weiterleitungs-Header: Caddy setzt X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host von sich aus und verwirft eingehende Werte dieser Felder, damit sie nicht gefälscht werden können. Und WebSockets laufen einfach durch, ohne die aus nginx bekannte Upgrade-Klausel.

Wo Caddy nginx nicht ersetzt

Ehrlichkeitshalber gehört die Gegenrichtung dazu. nginx hat ein deutlich grösseres Ökosystem an Modulen, mehr Feinsteuerung beim Caching und mehr Personen, die sich damit auskennen. Wer bereits eine gewachsene, funktionierende nginx-Konfiguration hat, gewinnt durch einen Wechsel wenig. Und Caddy hat eine architektonische Eigenheit, die überrascht: Erweiterungen sind einkompilierte Go-Module. Ein Plugin nachzurüsten bedeutet, das Binary neu zu bauen. Dafür gibt es einen bequemen Befehl, aber es bleibt ein anderes Modell als eine nachinstallierte .so-Datei — mit einer Nebenwirkung, auf die wir weiter unten zurückkommen.

Voraussetzungen für den Reverse Proxy

Vier Dinge müssen stimmen, bevor die erste Zeile Konfiguration Sinn ergibt.

• Ein Server mit Debian 12/13 oder Ubuntu 24.04 und Root- beziehungsweise sudo-Rechten. Ein Raspberry Pi reicht für den Heimgebrauch vollkommen aus, der Proxy selbst ist genügsam.
• Eine Domain, deren DNS-Einträge auf eure öffentliche IP zeigen. Bei wechselnder IP am Hausanschluss braucht es dafür einen dynamischen Eintrag, wie in unserer Anleitung zum DynDNS-Eintrag bei dynamischer IP beschrieben. Für jeden Dienst legt ihr eine eigene Subdomain an.
• Die Ports 80 und 443 müssen von aussen auf den Proxy zeigen. Wie das am Schweizer Router eingerichtet wird, steht in unserem Beitrag zur Portweiterleitung auf Swisscom- und UPC-Modems. Hängt ihr an einem DS-Lite-Anschluss ohne öffentliche IPv4-Adresse, hilft keine Weiterleitung — dann führt der Weg über einen VPS als Brücke, wie in Webdienste hinter DS-Lite verfügbar machen mit Wireguard gezeigt.
• Die Dienste laufen bereits und lauschen lokal. Ob nativ installiert oder über Docker, spielt keine Rolle. Wichtig ist, dass sie auf 127.0.0.1 gebunden sind und nicht auf 0.0.0.0 — sonst ist der Proxy umgehbar.

Läuft auf dem Rechner bereits ein Apache oder nginx auf Port 80 und 443, stoppt und deaktiviert ihn vorher. Zwei Programme auf demselben Port ergeben beim Start nur eine Fehlermeldung.

Caddy unter Debian und Ubuntu installieren

Die Distributionspakete hinken der Entwicklung meist hinterher. Nehmt deshalb das offizielle Repository des Projekts:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Das Paket bringt eine systemd-Unit mit und startet den Dienst sofort. Prüft danach die Version:

caddy version
systemctl status caddy

Ruft ihr jetzt die IP des Servers im Browser auf, begrüsst euch eine Startseite. Der Dienst läuft unter dem Benutzer caddy, die Konfiguration liegt in /etc/caddy/Caddyfile, und die Zertifikate landen später unter /var/lib/caddy/.local/share/caddy. Diese drei Pfade solltet ihr euch merken, sie beantworten später die meisten Fragen.

Die erste Caddyfile: ein Dienst, ein Zertifikat

Öffnet /etc/caddy/Caddyfile, löscht den mitgelieferten Inhalt und schreibt stattdessen:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

Das war die vollständige Konfiguration für einen Dienst mit gültigem Zertifikat und automatischer Weiterleitung von HTTP auf HTTPS. Der geschweifte Block ganz oben ist der globale Optionsblock. Er muss der erste Block der Datei sein und darf nur einmal vorkommen. Die Adresse unter email wird für das ACME-Konto verwendet; darüber informiert euch die Zertifizierungsstelle, wenn eine Erneuerung dauerhaft scheitert. Der zweite Block ist ein Site-Block: alles zwischen den Klammern gilt für Anfragen an diesen Hostnamen.

Formatiert und prüft die Datei, bevor ihr sie aktiviert:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Ein Hinweis zur Einrückung: Die Caddyfile erwartet Tabulatoren, keine Leerzeichen. caddy fmt --overwrite räumt das für euch auf, weshalb dieser Befehl der erste von dreien ist. Alle Unterbefehle sind dokumentiert, im Alltag braucht ihr vor allem diese drei.

Was beim ersten Neuladen tatsächlich passiert

Caddy liest aus dem Site-Block heraus, dass es ein Zertifikat für cloud.example.ch braucht, und beginnt sofort damit. Primäre Zertifizierungsstelle ist Let's Encrypt, bei Fehlern weicht Caddy automatisch auf ZeroSSL aus. Zur Validierung stehen die HTTP-Challenge über Port 80 und die TLS-ALPN-Challenge über Port 443 bereit; Caddy wählt zunächst zufällig und merkt sich, welcher Weg bei euch verlässlich funktioniert. Nach wenigen Sekunden ist das Zertifikat da und der Dienst über HTTPS erreichbar.

Zusehen könnt ihr dabei im Journal:

journalctl -u caddy -f

Und hier lauert die erste ernsthafte Falle. Solange die DNS-Einträge noch nicht stimmen oder die Portweiterleitung fehlt, scheitert die Validierung — und Let's Encrypt zählt mit. Nach den offiziellen Rate Limits sind pro Bezeichner und Konto fünf fehlgeschlagene Autorisierungen pro Stunde erlaubt, pro registrierter Domain 50 Zertifikate in sieben Tagen und für einen exakt gleichen Satz von Bezeichnern fünf Zertifikate in sieben Tagen. Wer eine Konfiguration in Ruhe durchprobieren will, schaltet deshalb vorher auf die Testumgebung um:

{
	email admin@example.ch
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

Die Zertifikate der Testumgebung sind im Browser ungültig, das ist beabsichtigt. Wenn alles steht, nehmt ihr die Zeile wieder heraus und ladet neu. Praktisch heisst das: erst mit Staging bauen, dann scharf schalten. Wer diese zwei Minuten überspringt, sitzt im schlechtesten Fall eine Woche auf einem gesperrten Bezeichner.

Drei Dienste hinter einer Adresse

Der eigentliche Gewinn zeigt sich erst ab dem zweiten Dienst. Jeder bekommt seinen eigenen Site-Block, jeder sein eigenes Zertifikat, alle teilen sich denselben Port:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	reverse_proxy 127.0.0.1:8000
}

fotos.example.ch {
	reverse_proxy 127.0.0.1:2283
}

Die Ports sind die Vorgaben der jeweiligen Projekte: 8000 für Vaultwarden, 2283 für Immich, 8080 für einen Nextcloud-Container hinter dem Proxy. Bemerkenswert ist vor allem, was hier nicht steht. Keine Upload-Grenze für Immich. Keine WebSocket-Klausel für Vaultwarden, dessen eigenes Caddy-Beispiel im Projekt-Wiki ebenfalls mit einer einzigen reverse_proxy-Zeile auskommt. Keine Zertifikatspfade, keine Cipher-Listen, kein Redirect-Block.

Liegt ein Dienst auf einem anderen Rechner im lokalen Netz, tragt ihr dort statt 127.0.0.1 dessen IP ein. Und wenn das Backend selbst schon HTTPS spricht, etwa mit einem selbstsignierten Zertifikat, sieht das so aus:

nas.example.ch {
	reverse_proxy https://192.168.1.50:5001 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

Das Überspringen der Zertifikatsprüfung ist hier vertretbar, weil die Strecke im eigenen Netz liegt und die Verschlüsselung nach aussen der Proxy übernimmt. Auf einer Verbindung über das Internet wäre es ein Fehler.

Nextcloud hinter dem Reverse Proxy richtig konfigurieren

Nextcloud ist der Dienst, bei dem am häufigsten etwas schiefgeht — nicht wegen Caddy, sondern weil Nextcloud sich selbst hinter einem Proxy falsch einschätzt. Es sieht eine unverschlüsselte Anfrage von 127.0.0.1 und baut daraus Links mit http://. Ergebnis: Anmeldeschleifen, kaputte Vorschaubilder, und im Log steht bei jedem Zugriff dieselbe IP-Adresse. Ergänzt deshalb in config/config.php:

'trusted_domains' => [
  'cloud.example.ch',
],
'trusted_proxies' => ['127.0.0.1'],
'forwarded_for_headers' => ['HTTP_X_FORWARDED_FOR'],
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.example.ch',
'overwrite.cli.url' => 'https://cloud.example.ch',

Die Bedeutung der Werte steht in der kommentierten Beispielkonfiguration im Nextcloud-Repository. trusted_proxies erlaubt Nextcloud, den weitergereichten Client-IPs überhaupt zu glauben, forwarded_for_headers legt fest, welchem Header dabei vertraut wird, und die drei overwrite-Werte korrigieren die Selbsteinschätzung bei der URL-Erzeugung. Läuft Nextcloud in einem Container, gehört unter trusted_proxies nicht 127.0.0.1, sondern die Adresse des Docker-Netzes.

Sicherheitskopfzeilen an einer Stelle statt in jedem Dienst

Der zweite grosse Vorteil eines zentralen Einstiegspunkts: Kopfzeilen, die für alle Dienste gelten sollen, schreibt ihr genau einmal. Caddy kennt dafür wiederverwendbare Bausteine, sogenannte Snippets, die in runden Klammern definiert und mit import eingebunden werden:

{
	header {
		Strict-Transport-Security "max-age=31536000"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "SAMEORIGIN"
		Referrer-Policy "no-referrer"
		-Server
	}
}

cloud.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8000
}

Das führende Minus vor Server löscht die Kopfzeile aus der Antwort. Bei Strict-Transport-Security ist Vorsicht angebracht: Die Anweisung sagt jedem Browser, diese Domain für die angegebene Dauer ausschliesslich über HTTPS anzusprechen — hier ein Jahr. Das ist erwünscht, aber es lässt sich nicht kurzfristig zurücknehmen. Nehmt die Zusätze includeSubDomains und preload erst dazu, wenn wirklich jede Subdomain dauerhaft per HTTPS erreichbar ist.

Zertifikate ohne offene Ports: die DNS-Challenge

HTTP- und TLS-ALPN-Challenge setzen voraus, dass die Zertifizierungsstelle euren Server von aussen erreicht. Das ist nicht immer der Fall: an einem DS-Lite-Anschluss fehlt die öffentliche IPv4-Adresse, manche Provider sperren Port 80, und für Dienste, die absichtlich nur im VPN erreichbar sind, gibt es gar keinen Weg von aussen. Ausserdem lassen sich Wildcard-Zertifikate ausschliesslich per DNS ausstellen.

Die DNS-Challenge dreht die Beweisrichtung um: Statt einer Datei auf eurem Server legt Caddy einen TXT-Eintrag in eurer DNS-Zone an. Damit braucht es keinen einzigen offenen Port — aber Schreibzugriff auf die Zone.

Plugin nachrüsten mit caddy add-package

Für jeden DNS-Anbieter gibt es ein eigenes Modul, und weil Caddy-Erweiterungen einkompiliert werden, braucht es ein neues Binary. Der eingebaute Befehl erledigt das:

sudo caddy add-package github.com/caddy-dns/cloudflare
caddy list-modules --packages | grep cloudflare
sudo systemctl restart caddy

Und damit zur angekündigten Nebenwirkung: caddy add-package ersetzt das vom Paketmanager installierte Binary. Beim nächsten apt upgrade überschreibt apt es wieder mit der Standardversion — das Plugin ist weg, die Caddyfile verweist auf ein Modul, das es nicht mehr gibt, und der Dienst startet nicht. Wer das vermeiden will, führt add-package nach jedem Upgrade erneut aus oder aktualisiert stattdessen mit caddy upgrade, das die installierten Module beibehält. Notiert euch die Zeile mit euren Paketen an einer Stelle, an der ihr sie wiederfindet.

Den API-Token sauber übergeben

Der Token gehört nicht in die Caddyfile, sondern in die Umgebung des Dienstes. Bei Cloudflare braucht er laut Modul-Dokumentation genau zwei Berechtigungen: Zone.Zone:Read und Zone.DNS:Edit, beschränkt auf die betroffenen Zonen. Legt ein systemd-Override an:

sudo systemctl edit caddy

Und tragt dort ein:

[Service]
Environment="CF_API_TOKEN=euer_token_hier"

In der Caddyfile wird der Wert dann als Platzhalter referenziert:

intern.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}
	reverse_proxy 127.0.0.1:3000
}

Die ältere Schreibweise mit getrennten zone_token- und api_token-Feldern taucht in vielen Anleitungen im Netz noch auf. Das Modul bezeichnet sie ausdrücklich als veraltet und behält sie nur aus Kompatibilitätsgründen — nehmt die einzeilige Variante.

Wildcard-Zertifikate

Steht die DNS-Challenge, könnt ihr ein einziges Zertifikat für alle Subdomains ausstellen lassen. Das reduziert die Zahl der ACME-Anfragen erheblich und hält euch von den Rate Limits fern:

*.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}

	@cloud host cloud.example.ch
	handle @cloud {
		reverse_proxy 127.0.0.1:8080
	}

	@vault host vault.example.ch
	handle @vault {
		reverse_proxy 127.0.0.1:8000
	}

	handle {
		abort
	}
}

Die mit @ beginnenden Ausdrücke sind Matcher, die den passenden Hostnamen herausgreifen. Der letzte handle-Block ohne Matcher fängt alles ab, was zu keinem Dienst gehört, und bricht die Verbindung ab — sonst würde jede erfundene Subdomain irgendwo landen. Beachtet dabei, dass ein Wildcard-Zertifikat nur eine Ebene abdeckt: *.example.ch gilt für cloud.example.ch, aber nicht für a.b.example.ch.

Betrieb: prüfen, neu laden, Logs lesen

Im laufenden Betrieb sind es vor allem drei Handgriffe. Nach jeder Änderung an der Caddyfile gilt dieselbe Reihenfolge wie oben: formatieren, validieren, neu laden. systemctl reload caddy übernimmt die neue Konfiguration ohne Verbindungsabbruch — ein restart ist nur nötig, wenn ihr das Binary getauscht oder die systemd-Unit geändert habt.

Standardmässig landet alles im Journal. Für einen einzelnen Dienst lohnt sich ein eigenes Zugriffsprotokoll, etwa um es später an CrowdSec zu übergeben:

cloud.example.ch {
	log {
		output file /var/log/caddy/cloud.log {
			roll_size 10MiB
			roll_keep 5
		}
	}
	reverse_proxy 127.0.0.1:8080
}

Das Verzeichnis muss dem Benutzer caddy gehören. Und ein Punkt, der gern vergessen wird: In eure Sicherung gehört nicht nur /etc/caddy, sondern auch /var/lib/caddy/.local/share/caddy. Dort liegen die Zertifikate, die privaten Schlüssel und der ACME-Kontoschlüssel. Ohne dieses Verzeichnis holt ein neu aufgesetzter Server zwar alle Zertifikate neu — aber jeder solche Durchlauf zählt auf die Rate Limits.

Stolperfallen, die euch einen Abend kosten

• Port 80 zugemacht. Viele schliessen ihn, weil ohnehin alles über HTTPS läuft. Dann fehlt die Weiterleitung für Besucher, die ohne Präfix tippen, und die HTTP-Challenge fällt als Ausweichweg weg. Lasst ihn offen, ausser ihr nutzt ausschliesslich die DNS-Challenge.
• Alter Webserver läuft noch. Ein address already in use im Journal bedeutet fast immer einen vergessenen Apache oder nginx.
• Dienst lauscht auf 0.0.0.0. Dann ist er direkt über seinen Port erreichbar, unverschlüsselt und ohne die gesetzten Kopfzeilen. Bindet Backends an 127.0.0.1 und blockt die Ports zusätzlich in der Firewall.
• Cloudflare-Proxy davor. Steht in eurem DNS die orange Wolke, terminiert Cloudflare TLS selbst und die TLS-ALPN-Challenge scheitert zwangsläufig. Dann führt der Weg über die DNS-Challenge.
• Konfiguration nicht validiert. systemctl reload mit einer fehlerhaften Datei lässt die alte Konfiguration aktiv und meldet den Fehler nur im Journal. Wer nicht hinsieht, wundert sich, warum die Änderung nichts bewirkt.
• Leerzeichen statt Tabulatoren. Erzeugt Fehlermeldungen, die auf den ersten Blick nichts mit Einrückung zu tun haben. caddy fmt --overwrite zuerst.

Was ihr tun könnt

• Legt für jeden Dienst eine eigene Subdomain an, statt Ports nach aussen zu öffnen. Das kostet nichts und ist die Grundlage für alles Weitere.
• Baut die erste Konfiguration gegen den Staging-Endpunkt von Let's Encrypt. Zwei zusätzliche Minuten, die euch im Fehlerfall eine Woche Wartezeit ersparen.
• Bindet alle Backends auf 127.0.0.1 und prüft mit ss -tlnp, ob sich noch etwas an einer öffentlichen Adresse festhält.
• Zieht die Sicherheitskopfzeilen in ein Snippet und importiert es in jeden Site-Block, statt sie in jedem Dienst einzeln zu pflegen.
• Nehmt /var/lib/caddy/.local/share/caddy in die Sicherung auf.
• Wenn ihr Plugins nachrüstet: haltet die add-package-Zeile fest und prüft nach jedem Systemupdate mit caddy list-modules --packages, ob sie noch da sind.

Fazit: Caddy macht TLS zur Standardeinstellung statt zur Bastelaufgabe

Die verbreitete Kombination aus nginx und Certbot funktioniert seit Jahren zuverlässig, und niemand muss sie ersetzen. Aber sie besteht aus vier Teilen, die zusammenarbeiten müssen: Webserver, ACME-Client, Timer und Konfigurationsdateien, die zwei Programme gleichzeitig bearbeiten. Jeder dieser Teile hat schon einmal jemandem ein abgelaufenes Zertifikat beschert.

Caddy schneidet diese Kette auf ein Teil zusammen. Sechs Zeilen Konfiguration reichen für einen Dienst mit gültigem Zertifikat, automatischer Erneuerung, HTTP-Weiterleitung, HTTP/2, HTTP/3 und funktionierenden WebSockets. Dass Immich in der eigenen Dokumentation eine halbe Seite nginx neben drei Zeilen Caddy stellt, ist keine Werbung des Caddy-Projekts, sondern die Einschätzung eines unbeteiligten Dritten.

Der Preis dafür sind weniger Stellschrauben und ein Erweiterungsmodell, das bei jedem Systemupdate Aufmerksamkeit verlangt. Für die überwiegende Mehrheit selbst gehosteter Installationen ist das ein guter Handel. Verschlüsselung sollte der unauffällige Normalzustand sein und nicht die Aufgabe, die dreimal im Jahr um drei Uhr morgens Alarm schlägt — und genau daran gemessen ist Caddy für Selfhoster derzeit die vernünftigste Wahl.

Quellen und weiterführende Links

• Caddy Documentation — Install, offizielle Installationswege inklusive apt-Repository
• Caddy Documentation — Automatic HTTPS, Ablauf der Zertifikatsbeschaffung und Challenge-Auswahl
• Caddy Documentation — reverse_proxy, Syntax, gesetzte Header, Transport und Lastverteilung
• Caddy Documentation — tls, DNS-Challenge, Propagation und alternative Zertifizierungsstellen
• Caddy Documentation — Global Options, globaler Optionsblock mit email und acme_ca
• Caddy Documentation — Command Line, validate, fmt, reload, add-package und upgrade
• Caddy Documentation — Keeping Caddy Running, systemd-Dienst, Benutzer und Datenverzeichnisse
• Caddy Documentation — request_body, Begrenzung der Anfragegrösse
• caddyserver/caddy — Releases, Versionsstand v2.11.4 vom 3. Juni 2026
• caddy-dns/cloudflare, Konfigurationssyntax und benötigte Token-Berechtigungen
• Let's Encrypt — Rate Limits, verbindliche Grenzwerte für Ausstellung und Fehlversuche
• nginx — client_max_body_size, Vorgabewert 1 MB und Verhalten bei Überschreitung
• Immich — Reverse Proxy, Vergleich der nginx- und Caddy-Konfiguration
• Vaultwarden Wiki — Proxy examples, Caddy-Beispiel des Projekts
• Nextcloud — config.sample.php, kommentierte Referenz zu trusted_proxies und den overwrite-Werten

The post Caddy Reverse Proxy einrichten: HTTPS ohne Certbot appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht zuerst: CalyxOS gibt es weiterhin, mit einer nach eigenen Angaben robusteren Sicherheitsarchitektur als zuvor. Die schlechte Nachricht folgt sofort: Wer während der Pause auf einem alten Build sass, kommt an einer kompletten Neuinstallation nicht vorbei. Ein einfaches Update über die Luftschnittstelle reicht nicht, und genau dieser Teil geht in den bisherigen Meldungen zum Comeback oft unter.

CalyxOS ist ein von der gemeinnützigen Calyx-Stiftung entwickeltes, Google-freies Custom-ROM für Android, das gezielt Journalisten, Aktivisten und sicherheitsbewusste Privatnutzer adressiert, unter anderem mit integriertem Tor-Zugang über die App Orbot und einer optionalen MicroG-Kompatibilitätsschicht für den Alltag. Gerade für dieses Zielpublikum wiegt eine elfmonatige Lücke bei Sicherheitsupdates besonders schwer, weshalb sich ein genauer Blick auf das Comeback lohnt, statt es nur als erfreuliche Randnotiz abzuhaken.

Was am 1. Juli zurückkam: CalyxOS 7.2.2.0

Mit der Ankündigung vom 1. Juli 2026 erklärt das Calyx Institute die Entwicklungspause für beendet. Version 7.2.2.0 versteht sich laut Projekt nicht als einmaliger Nachzügler, sondern als Rückkehr zum regulären Auslieferungsrhythmus mit voller Wartung, also mit Sicherheitsupdates in gewohnter Kadenz statt einer weiteren Ankündigung ohne Substanz. Nutzer, die bereits den im Mai 2026 veröffentlichten Testbuild 7.2.1.0 installiert hatten, erhielten das Update automatisch über die Luftschnittstelle. Für alle anderen beginnt die Rückkehr mit einer Neuinstallation, dazu weiter unten mehr.

Elf statt sechs Monate: Warum die Pause so lange dauerte

Im Brief an die Community vom 1. August 2025 hatte das Projekt eine Pause von vier bis sechs Monaten angekündigt. Am Ende wurden daraus knapp elf Monate. Eine Begründung für die zusätzliche Verzögerung hat CalyxOS nie im Detail nachgeliefert, weder in weiteren Blogposts noch in der Ankündigung des Comebacks selbst.

Der Weggang von Nicholas Merrill und Chirayu Desai

Auslöser der Pause war der Abgang zweier Schlüsselpersonen. Nicholas Merrill, Präsident und Gründer des Calyx Institute, verliess die Organisation nach eigenen Angaben, um sich anderen Projekten zu widmen, nach mehr als 25 Jahren im Datenschutz-Umfeld. Parallel dazu gab Chirayu Desai, technischer Leiter von CalyxOS, seine Rolle ab. Beide Abgänge trafen das Projekt an neuralgischen Stellen, Merrill auf der institutionellen, Desai auf der technischen Seite. Die Führung des Instituts übernahm im Anschluss Ellen McDermott, zuvor bereits interimistische Geschäftsführerin.

Sicherheitsaudits statt Schnellschuss

Nach dem Abgang von Personen mit weitreichenden Zugriffsrechten ist eine Rotation der Signing Keys und ein Sicherheitsaudit laut dem Brief an die Community "Security Best Practice", nicht Kür. Für ein Betriebssystem, dessen gesamtes Sicherheitsmodell auf einer vertrauenswürdigen Signaturkette beruht, bei der jedes Update gegen den öffentlichen Schlüssel des Projekts verifiziert wird, ist das die einzig verantwortbare Reaktion. Elf statt sechs Monate ohne Sicherheitsupdates bleiben trotzdem eine lange Zeit für ein System, dessen zentrales Versprechen genau darin besteht, Nutzer vor solchen Lücken zu schützen.

Die neue Signing-Infrastruktur: ein HSM statt einzelner Personen

Technisch fasst das Projekt die Lehre aus der Pause in einer neuen, quelloffenen HSM-basierten Signing-Lösung zusammen. Ein Hardware Security Module (HSM) ist ein dediziertes Gerät, das kryptografische Schlüssel physisch abgeschottet erzeugt, speichert und verwendet, ohne sie jemals im Klartext preiszugeben. Anwendungen schicken lediglich eine Signieranfrage, das Schlüsselmaterial selbst verlässt das Modul nie. Der Weggang zweier Personen genügte offenbar, um das gesamte Projekt zum Stillstand zu bringen, was darauf hindeutet, dass ein Teil der Verantwortung für den Signierprozess bislang an einzelnen Personen statt ausschliesslich an Systemen hing. Die neue Lösung soll laut Projekt genau diesen Single Point of Failure beseitigen.

Der Fachbegriff für den zugrundeliegenden Vorgang ist Signing Ceremony: ein protokollierter, oft unter mehreren Zeugen und teils offline durchgeführter Prozess, bei dem die kryptografischen Schlüssel innerhalb des HSM erzeugt werden, ohne dass eine einzelne Person jemals allein Zugriff auf das vollständige Schlüsselmaterial erhält. Solche Zeremonien sind aus dem DNSSEC-Root-Signing oder von Zertifizierungsstellen bekannt, wo sie seit Jahren Standard sind, um genau das Szenario zu verhindern, das CalyxOS im August 2025 in die Pause zwang: den faktischen Verlust der Kontrolle über kritisches Schlüsselmaterial durch den Abgang einzelner Personen.

Trail of Bits hat geprüft, allerdings mit engem Zuschnitt

Ergänzend zur neuen Infrastruktur hat CalyxOS ein Sicherheitsaudit durch Trail of Bits in Auftrag gegeben, eine der bekanntesten unabhängigen Sicherheitsfirmen im Open-Source-Umfeld. Der Bericht vom Januar 2026 ist öffentlich einsehbar, das ist positiv zu vermerken. Er prüft aber nicht CalyxOS als Ganzes, sondern ausdrücklich die Skripte der HSM-Provisioning-Zeremonie, also den Prozess, mit dem die neuen Signierschlüssel überhaupt erst sicher erzeugt wurden. Das ist ein sinnvoller und naheliegender Prüfumfang angesichts des Auslösers der Pause, aber kein Ersatz für ein umfassendes Audit des gesamten Systems. Wer aus der Erwähnung von "Trail of Bits" auf eine Vollprüfung schliesst, überschätzt, was der Bericht tatsächlich abdeckt.

Android 16 statt 17, und was CalyxOS 8 noch nicht kann

CalyxOS 7.2.2.0 basiert auf Android 16, obwohl Google mit Android 17 bereits die nächste Hauptversion veröffentlicht hat. Die Portierung auf Android 17 als CalyxOS 8 läuft laut Projekt, befindet sich aber noch in einer frühen Phase, ein Termin steht nicht fest. Dass ein Custom-ROM der jeweiligen Google-Basis einige Monate hinterherläuft, ist für sich genommen normal. Nach einer elfmonatigen Pause ist der Rückstand aber grösser als sonst, was die Frage aufwirft, wie schnell das Projekt beim nächsten grossen Versionssprung wieder auf Tempo kommt.

Neue Geräte: SHIFTphone 8 kommt, Google Pixel 10 fehlt

Auf der Geräteliste taucht mit dem Comeback erstmals das SHIFTphone 8 auf, ein in Deutschland konzipiertes und auf Reparierbarkeit ausgelegtes Gerät des Herstellers Shift. Damit wächst die Unabhängigkeit von Google-Pixel-Hardware, ein Umstand, den wir bereits im Zusammenhang mit den Verschärfungen bei Custom-ROMs für Pixel-Geräte eingeordnet haben. Auffällig zugleich: Das aktuelle Google Pixel 10 fehlt in der Kompatibilitätsliste. Ob das an fehlendem Entwicklungsstand nach der Pause liegt oder an grundsätzlicheren Hürden, lässt das Projekt offen, ein Punkt, den Kaufinteressenten vor einer Anschaffung gezielt in der aktuellen Geräteliste prüfen sollten, statt sich auf ältere Angaben zu verlassen.

Die Geräteunterstützung von CalyxOS war schon vor der Pause breiter als bei den meisten anderen Custom-ROMs. Neben mehreren Google-Pixel-Generationen zählen dazu diverse Fairphone-Modelle und eine wachsende Zahl an Motorola-Geräten, die das Projekt bereits im Mai 2025 um vier zusätzliche, vergleichsweise günstige Modelle erweiterte, namentlich das Moto G 5G (2024), G34 5G, G45 5G und G84 5G. Mit dem SHIFTphone 8 kommt nun erstmals ein in Deutschland konzipiertes Gerät hinzu, das sein Hersteller Shift ausdrücklich modular und reparierbar auslegt. Für Nutzer, die weder Google-Hardware noch ein Fairphone wollen, ist das die erste echte CalyxOS-Option ausserhalb dieser beiden Ökosysteme. Die Auswahl der Motorola-Modelle begründete das Projekt seinerzeit ausdrücklich mit vergleichsweise günstigen Preisen und einer deutlich breiteren weltweiten Verfügbarkeit als bei Pixel-Geräten, die in vielen Ländern nur eingeschränkt oder gar nicht offiziell erhältlich sind, ein Kriterium, das beim SHIFTphone 8 in ähnlicher Form gelten dürfte.

Das August-Update zeigt: der reguläre Rhythmus ist zurück

Bereits am 7. August 2026, gut fünf Wochen nach dem Comeback, folgte mit CalyxOS 7.2.4.20 das erste reguläre Sicherheitsupdate nach der Rückkehr. Für ein Projekt, dessen zentrales Versprechen zuletzt gerade die Verlässlichkeit von Sicherheitsupdates war, ist das ein wichtigeres Signal als das Comeback selbst. Ein einzelner Release ist eine Ankündigung, ein zweiter im gewohnten Rhythmus ist ein erster Beleg dafür, dass die neue Infrastruktur im Alltag trägt.

Community-Neustart: neue Rollen, neue Matrix-Infrastruktur

Auch personell und kommunikativ hat sich das Projekt während der Pause neu sortiert. Laut der Newsseite übernahm Habib die Verantwortung für die Infrastruktur von Nat, während Aayush, bislang zuständig für den Aurora Store innerhalb des Projekts, das Team verlassen hat. Neu hinzugekommen ist zudem ein dedizierter Systemadministrator, dessen Aufgabe erkennbar direkt aus der Pause folgt: eine Infrastruktur, die nicht mehr von einzelnen Freiwilligen nebenbei mitbetreut wird. Die Matrix-Kanäle der Community wurden auf Version 12 des Protokolls angehoben, und für den direkten Austausch mit dem Projekt entstand ein neuer, zentraler Matrix Space. Für Nutzer, die Bugs melden oder den Fortschritt bei CalyxOS 8 auf Android-17-Basis verfolgen wollen, ist das seit dem Comeback der naheliegendste Anlaufpunkt.

Die unbequeme Wahrheit für Alt-Nutzer: Neuinstallation statt Update

Die Versionsgrenze: 6.10.10/20 und älter

Der Teil, der in den bisherigen Meldungen zum Comeback oft zu kurz kommt: Wer aktuell CalyxOS 6.10.10/20 oder älter nutzt, oder ein beliebiges anderes Android-Betriebssystem, kommt nicht mit einem Update auf 7.2.2.0, sondern muss laut offizieller Ankündigung eine komplette Neuinstallation durchführen. Wörtlich heisst es dort, wer eine alte Version oder ein anderes Android-Betriebssystem nutze, benötige eine "clean install". Ein Update über die Luftschnittstelle erhalten ausschliesslich Nutzer, die bereits den Testbuild 7.2.1.0 installiert hatten. Der Grund liegt in der neuen Signing-Infrastruktur: Alte Builds sind gegen den alten Schlüssel signiert, neue Builds gegen den neuen, und einen Verifizierungspfad zwischen beiden gibt es nicht.

Seedvault als Rettungsanker vor dem Wipe

Eine Neuinstallation bedeutet ein vollständiges Löschen des Geräts. Wer seine Daten vorher nicht sichert, verliert sie. CalyxOS bringt mit Seedvault ein eigenes Backup-Werkzeug mit, das wir bereits in einer eigenen Anleitung zur lokalen Sicherung und Wiederherstellung beschrieben haben, inklusive der Einschränkung, dass Backups nur zwischen Geräten derselben ROM-Familie funktionieren. Wer stattdessen von einem Stock-Android- oder iPhone-Gerät kommt oder ganz allgemein Daten übertragen will, findet den passenden Weg in unserer Anleitung zum Datentransfer auf ein Custom-ROM. Für die eigentliche Ersteinrichtung nach dem Flashen, inklusive der einmaligen und später nicht mehr nachholbaren Entscheidung für oder gegen MicroG, verweisen wir auf unseren CalyxOS-Einsteiger-Guide, der das Setup Schritt für Schritt begleitet.

Was ihr tun könnt

• Nutzt ihr den Testbuild 7.2.1.0, prüft in den Systemeinstellungen, ob das Update auf 7.2.2.0 bereits angekommen ist, notfalls manuell nach Updates suchen.
• Nutzt ihr CalyxOS 6.10.10/20 oder älter, erstellt zuerst ein Seedvault-Backup und plant danach eine komplette Neuinstallation gemäss offizieller Anleitung ein.
• Lief euer Gerät seit der Pause ungepatcht, verzichtet bis zur Neuinstallation auf sensible Nutzung wie Online-Banking oder Zwei-Faktor-Codes auf diesem Gerät.
• Sucht ihr ein neues Gerät, prüft die aktuelle Geräteliste inklusive SHIFTphone 8 vor dem Kauf, statt euch auf ältere Kompatibilitätsangaben zu verlassen, insbesondere weil das Pixel 10 aktuell fehlt.
• Seid ihr unsicher, ob CalyxOS die richtige Wahl bleibt, wartet die nächsten ein bis zwei Update-Zyklen ab, bevor ihr produktive Daten auf das System verlagert.
• Wollt ihr Fehler melden oder den Fortschritt bei CalyxOS 8 verfolgen, nutzt den neuen zentralen Matrix Space des Projekts statt veralteter Kanäle aus der Zeit vor der Pause.

Einordnung: Ist CalyxOS nach diesem Jahr noch die richtige Wahl?

Die Fakten sprechen für einen vorsichtigen Vertrauensvorschuss, nicht für eine bedingungslose Empfehlung. Positiv: Das Projekt hat die Pause genutzt, um eine strukturelle Schwäche zu beheben, statt einfach weiterzumachen wie zuvor. Eine HSM-basierte Signing-Infrastruktur, die nicht mehr an einzelne Personen gebunden ist, ist eine echte Verbesserung gegenüber dem Zustand vor August 2025, und genau die Art von Fehler, die einem Open-Source-Projekt mit begrenzten Ressourcen passieren kann, ohne dass böser Wille dahintersteckt. Das zweite Sicherheitsupdate innerhalb weniger Wochen ist ein weiteres gutes Zeichen, ebenso die Entscheidung, den HSM-Prozess auditieren und den Bericht öffentlich zugänglich zu lassen.

Negativ: Elf Monate ohne Sicherheitsupdates sind für ein sicherheitsorientiertes Betriebssystem ein Zeitraum, den man nicht relativieren sollte, nur weil das Projekt ihn am Ende sauber gelöst hat. Wer in dieser Zeit ein Gerät mit sensiblen Daten weiterbetrieben hat, war real exponiert, unabhängig davon, wie überzeugend die Lösung im Nachhinein aussieht. Und das Audit deckt, wie oben beschrieben, nur einen Ausschnitt ab, nicht das Gesamtsystem. Beides zusammen ergibt kein Bild von Sorglosigkeit, aber auch keinen Freifahrtschein.

Für Nutzer, die primär auf Pixel-Hardware setzen, bleibt GrapheneOS mit seinem durchgehend gepflegten Update-Zyklus während der gesamten CalyxOS-Pause die robustere Wahl. Wer wie SHIFTphone-Nutzer keine praktikable Alternative zu CalyxOS auf seiner Hardware hat, oder wer CalyxOS aus anderen Gründen, etwa der MicroG-Unterstützung, bevorzugt, kann nach dem Comeback zurückkehren, sollte die Entwicklung in den kommenden Monaten aber aktiv beobachten statt sie auf Autopilot zu stellen.

Der Vergleich mit GrapheneOS macht dabei einen Unterschied im Ansatz deutlich, nicht nur einen Unterschied im Marktanteil. GrapheneOS verzichtet bewusst auf jede Google-Kompatibilitätsschicht und auf Support für Nicht-Pixel-Hardware, wodurch sich das Projekt auf eine einzige, eng kontrollierte Gerätefamilie konzentrieren kann. CalyxOS verfolgt mit MicroG-Option, breiterer Geräteunterstützung und eingebautem Tor-Zugang über Orbot einen bewusst offeneren, alltagstauglicheren Ansatz, der aber auch mehr bewegliche Teile und damit mehr potenzielle Fehlerquellen mit sich bringt. Die elfmonatige Pause zeigt, dass dieser breitere Zuschnitt nicht nur softwareseitig, sondern auch organisatorisch seinen Preis hat: Mehr Zielgruppen und mehr unterstützte Geräte bedeuten auch mehr Abhängigkeit von einzelnen Personen, wenn die Organisation dahinter nicht entsprechend robust aufgestellt ist.

Warum das Vertrauensproblem über CalyxOS hinausreicht

Die Pause bei CalyxOS ist kein Einzelfall im Ökosystem der Custom-ROMs, sondern das Symptom eines strukturellen Problems: Die meisten dieser Projekte werden von kleinen, teils ehrenamtlichen Teams getragen, die gegen einen Konzern antreten, der über ungleich mehr Ressourcen verfügt. Wir haben das bereits im Zusammenhang mit Googles schrittweiser Schliessung von Android eingeordnet: Je mehr Hürden Google für alternative Systeme aufbaut, etwa bei Zertifizierung oder beim Zugriff auf Sicherheitspatches, desto weniger Spielraum bleibt Projekten wie CalyxOS, um den Ausfall von Schlüsselpersonen abzufedern. Das gilt umso mehr, seit Google auch die technischen Voraussetzungen für Custom-ROMs auf eigener Pixel-Hardware verschärft hat, wie wir weiter oben bereits verlinkt haben. Ein Team, das ohnehin am Limit arbeitet, hat keine Redundanz übrig, wenn ausgerechnet Gründer und technischer Leiter gleichzeitig gehen.

Für Nutzer bedeutet das: Die Wahl eines Custom-ROMs ist nie nur eine technische Entscheidung, sondern auch eine Wette auf die organisatorische Stabilität eines kleinen Teams. CalyxOS hat diese Wette in den vergangenen elf Monaten sichtbar gemacht und, nach aktuellem Stand, für sich entschieden. Ob das auch beim nächsten unerwarteten Weggang gilt, lässt sich aus einem einzelnen erfolgreichen Comeback nicht ableiten, und genau deshalb bleibt eine gesunde Portion Wachsamkeit angebracht, auch nach diesem an sich guten Nachrichtentag für das Projekt.

Diese Verfügbarkeit ist dabei kein Nischenthema für Bastler. In einem politischen Klima, das mit Debatten um Chatkontrolle, dem Going-Dark-Paket und wiederkehrenden Vorstössen zur Ausweispflicht im Netz eher auf weniger als auf mehr Kontrolle über das eigene Gerät hinausläuft, ist die Existenz unabhängiger, vertrauenswürdiger Custom-ROMs Teil der Handlungsfähigkeit gegenüber genau solchen Vorhaben. Ein Comeback wie das von CalyxOS betrifft deshalb nicht nur dessen bestehende Nutzerbasis, sondern die Frage, wie viele ernstzunehmende Alternativen zu Googles Vorgaben am Ende überhaupt übrig bleiben.

Fazit: CalyxOS ist zurück, aber Vertrauen ist kein Versionssprung

CalyxOS 7.2.2.0 ist mehr als eine Formsache. Das Projekt hat eine echte strukturelle Schwäche behoben und liefert mit dem August-Update bereits einen ersten Beweis, dass der neue Prozess im Alltag trägt. Wer während der Pause gewartet hat, bekommt dafür aber keine bequeme Rückkehr geschenkt, sondern eine Neuinstallation mit allem, was dazugehört: Backup, Zeitaufwand und im Zweifel eine neue Entscheidung über MicroG. Das ist der Preis für ein Projekt, das seine Fehler ernst genommen hat, statt sie zu vertuschen. Genau deshalb verdient CalyxOS nach diesem Jahr keinen bedingungslosen Vertrauensvorschuss, aber eine faire zweite Chance, mit wachsamem Blick auf die nächsten Update-Zyklen.

Quellen und weiterführende Links

• CalyxOS: "CalyxOS is back" (1. Juli 2026)
• CalyxOS: "A letter to our community" (1. August 2025)
• Calyx Institute: Statement on Leadership Change
• CalyxOS News-Übersicht (u. a. August-Sicherheitsupdate 7.2.4.20)
• CalyxOS Device Support Guide
• Trail of Bits: Security Review, HSM Provisioning Ceremony Scripts (Januar 2026)

The post CalyxOS ist zurück – und verlangt eine Neuinstallation appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Debatte darüber verläuft bislang schlecht. Auf der einen Seite steht eine Beruhigungskommunikation, die Fragen mit Zusicherungen beantwortet. Auf der anderen ein Reflex, der jeden digitalen Euro sofort zum Sozialkreditsystem erklärt und dabei mit Behauptungen arbeitet, die einer Prüfung nicht standhalten. Beides hilft euch nicht. Deshalb hier der Versuch, das entlang der Dokumente auseinanderzunehmen: was das Ding ist, was tatsächlich beschlossen wurde, was mit der Programmierbarkeit wirklich passiert ist und wo die realen Risiken liegen.

Was der digitale Euro überhaupt ist

Um das Risiko einzuschätzen, müsst ihr wissen, welche Art von Geld hier entsteht. Und das ist tatsächlich eine neue.

Das Guthaben auf eurem Bankkonto gehört euch nicht in dem Sinn, in dem euch ein Zwanziger im Portemonnaie gehört. Es ist eine Forderung gegen eure Bank. Geht die Bank pleite, ist diese Forderung nur so viel wert, wie die Einlagensicherung hergibt. Bargeld dagegen ist eine direkte Verbindlichkeit der Zentralbank. Kein Dritter steht dazwischen, keine Bonität, kein Ausfallrisiko, keine Zustimmung nötig.

Der digitale Euro ist der Versuch, diese zweite Eigenschaft in die digitale Welt zu bringen: Zentralbankgeld, das ihr direkt haltet, nur ohne Papier. Fachlich heisst so etwas Central Bank Digital Currency, kurz CBDC. Ausgegeben würde er von der EZB, verteilt aber über eure Bank oder einen anderen Zahlungsdienstleister. Ein Konto bei der EZB bekommt ihr also nicht, die Kundenbeziehung bleibt, wo sie ist. Für Privatpersonen sollen die Grundfunktionen kostenlos sein.

Was der digitale Euro ausdrücklich nicht ist: eine Kryptowährung. Es gibt keine feste Obergrenze der Geldmenge, keine offene Teilnahme am Netzwerk und keine Möglichkeit für euch, die Regeln durch den Betrieb einer eigenen Node mitzubestimmen. Ein digitaler Euro ist immer genau ein Euro und unterliegt derselben Geldpolitik wie der auf eurem Konto. Wer ihn als europäische Antwort auf Bitcoin verkauft, verkauft eine Kategorienverwechslung.

Das eigentliche Motiv ist ohnehin ein anderes. Der europäische Zahlungsverkehr läuft im Alltag über Visa, Mastercard, PayPal, Apple Pay und Google Pay, also über amerikanische Infrastruktur mit amerikanischer Rechtsanbindung. Der digitale Euro ist in erster Linie ein Souveränitätsprojekt, und das ist ein nachvollziehbares Ziel. Es sagt nur nichts darüber aus, wie das Ergebnis gebaut wird. Souveränität nach aussen und Kontrolle nach innen schliessen sich nicht aus.

Das zweistufige Modell und wer welche Daten sieht

Der Aufbau ist zweistufig, und das ist für die Datenschutzfrage entscheidender als jede Absichtserklärung.

Stufe eins ist die EZB. Sie gibt das Geld aus und betreibt die Abwicklung im Hintergrund. Stufe zwei sind die Zahlungsdienstleister, also Banken und ähnliche Anbieter, die euch das Wallet bereitstellen, euch identifizieren, die Geldwäscheprüfung durchführen und die Zahlungen initiieren. Genau dort liegt die Verknüpfung zwischen eurer Person und euren Transaktionen. Nicht bei der EZB.

Wenn die EZB also sagt, sie könne Transaktionen nicht bestimmten Personen zuordnen, dann ist das im Rahmen dieses Modells korrekt. Es beschreibt aber nur die eine Stufe. Die andere Stufe kennt euch mit Namen, Adresse, Ausweisnummer und vollständiger Zahlungshistorie, und sie unterliegt derselben Aufsicht, denselben Auskunftspflichten und denselben Melderegimes wie heute schon euer Bankkonto. Die Aussage „das Eurosystem kann euch nicht identifizieren" ist deshalb kein Datenschutzversprechen, sondern eine Beschreibung der Zuständigkeitsverteilung.

Der Unterschied zu heute ist trotzdem real, nur an anderer Stelle: Heute verteilen sich eure Zahlungsdaten auf Bank, Kartenanbieter, PayPal und Bargeld. Beim digitalen Euro entsteht ein einheitliches, europaweit standardisiertes Format über ein Zahlungsmittel, das per Gesetz überall akzeptiert werden muss. Einheitliche Formate sind gut für Interoperabilität und gut für Auswertung. Beides gleichzeitig.

Was im Juni tatsächlich beschlossen wurde

Vier Punkte aus dem Ausschussbeschluss sind für euch relevant, und sie werden in der öffentlichen Debatte selten zusammen genannt.

Erstens die Haltegrenze. Wie viel digitale Euro ihr besitzen dürft, wird gedeckelt. Die konkrete Zahl steht nicht im Gesetz, sondern soll von der Kommission auf Empfehlung der EZB festgelegt und mindestens alle zwei Jahre überprüft werden. Der offizielle Grund ist die Sorge vor einem digitalen Bankrun: Wenn bei der ersten Krisenmeldung alle ihr Geld aus der Geschäftsbank in Zentralbankgeld umschichten, kippt das Bankensystem innerhalb von Stunden statt Tagen. Das Argument ist ernst zu nehmen, es beschreibt ein echtes Problem. Es bedeutet aber auch, dass eine per Rechtsakt änderbare Zahl darüber bestimmt, wie viel ausfallsicheres Geld ihr halten dürft.

Zweitens der Status als gesetzliches Zahlungsmittel. Die meisten Unternehmen müssen den digitalen Euro annehmen. Ausgenommen sind Selbständige sowie Klein- und Kleinstunternehmen ohne bestehende digitale Zahlungsmöglichkeit. Annahmepflicht heisst: Die Verbreitung entsteht nicht durch Nachfrage, sondern durch Vorschrift. Ein Produkt, das sich am Markt durchsetzen müsste, würde anders gebaut als eines, das ohnehin akzeptiert werden muss.

Drittens der Offline-Modus. Gezahlt wird dabei über ein lokales Speichermedium, also Hardware, die den Betrag ohne Netzverbindung hält. Geht das Gerät verloren, ist das Geld weg, eine Erstattung ist nicht vorgesehen.

Viertens der Zeitplan. Nach der Zulassung folgt eine Einführungsphase von mindestens 24 Monaten. Der Rat hatte seine Verhandlungsposition bereits im Dezember 2025 festgelegt, der Verfahrensstand lässt sich im Legislative Train des Parlaments nachverfolgen.

Die Programmierbarkeit ist nicht verschwunden, sie wurde umbenannt

Das ist der Punkt, an dem es wirklich interessant wird, und der Punkt, den die Beruhigungskommunikation am gründlichsten verfehlt.

Die offizielle Aussage lautet: Der digitale Euro wird kein programmierbares Geld. Das stimmt, aber nur, weil „programmierbares Geld" sehr eng definiert wurde. Die Begründung des Verordnungsvorschlags COM(2023) 369 formuliert es so: Gemeint sind Einheiten, die aufgrund ihnen innewohnender Ausgabebedingungen nur für bestimmte Waren oder Dienstleistungen verwendet werden können, oder die zeitlichen Beschränkungen unterliegen, nach denen sie nicht mehr nutzbar sind. Verboten ist also Geld mit eingebautem Verfallsdatum oder eingebauter Verwendungsbindung. Nicht mehr und nicht weniger.

Was ausdrücklich nicht verboten, sondern vorgesehen ist, steht wenige Seiten weiter. Der Vorschlag widmet den bedingten Zahlungstransaktionen einen eigenen Artikel. Und in den Erwägungsgründen benennt die Verordnung selbst, dass es um dieselbe Sache geht: Dort ist von der Nachfrage nach „programmierbaren Zahlungen" die Rede, die im Kontext dieser Verordnung als bedingte Zahlungen bezeichnet werden. Auch die EZB selbst beschreibt, dass Zahlungsdienstleister auf dieser Basis Mehrwertdienste entwickeln könnten, ausdrücklich genannt: bedingte Zahlungen.

Damit liegt die Sache offen. Die Fähigkeit, Bedingungen auszuwerten und Zahlungen nur bei deren Erfüllung auszulösen, ist Bestandteil des Systems. Sie muss es sein, sonst gäbe es keine bedingten Zahlungen. Der Unterschied zwischen erlaubt und verboten liegt nicht in der Technik, sondern allein darin, wo die Bedingung angeschrieben steht: an der Zahlung oder an der Geldeinheit. Das ist keine technische Grenze, das ist eine juristische Kategorie über einer Infrastruktur, die beides kann.

Der Wirtschaftsjournalist Norbert Häring hat das im Juni 2026 als Mogelpackung bezeichnet und den Kern in einem Satz zusammengefasst: Die interessanten und die gefährlichen Anwendungsfälle sind die, bei denen sich die Programmierung auf den Besitzer des Geldes bezieht. Seine Schlussfolgerungen muss niemand teilen, um zu sehen, dass die Beobachtung sitzt. Ob eine Sozialleistung nur für Heizkosten verwendbar ist, weil das Geld es so vorschreibt, oder weil die auszahlende Stelle eine entsprechende Bedingung an die Zahlung geknüpft hat, macht für den Empfänger keinen Unterschied.

Und selbst wenn das Verbot programmierbaren Geldes im endgültigen Text als eigener, verbindlicher Absatz stehen bleibt: Ein Verbot in einer Verordnung ist ein Satz in einer Verordnung. Verordnungen werden im selben ordentlichen Gesetzgebungsverfahren geändert, in dem sie entstanden sind. Wie belastbar dieses Verfahren gegen politischen Druck ist, liess sich im Juli bei der Abstimmung zur Chatkontrolle in Echtzeit beobachten.

Der entscheidende Satz lautet deshalb: Nicht die Funktion wurde entfernt, sondern ihre Nutzung untersagt. Das ist ein gewaltiger Unterschied. Eine Funktion, die nicht existiert, muss neu gebaut werden, und das fällt auf, das kostet Jahre und es gibt eine Debatte darüber. Eine Funktion, die existiert und nur nicht verwendet werden darf, muss lediglich freigeschaltet werden, wenn die Umstände es angeblich erfordern.

Der Blick nach China korrigiert die Debatte, statt sie zu bestätigen

An dieser Stelle kommt in fast jeder Diskussion der Verweis auf den digitalen Yuan mit Verfallsdatum. Der ist so verbreitet wie falsch, und wer die Kritik am digitalen Euro ernst meint, sollte ihn nicht wiederholen.

Der e-CNY der chinesischen Zentralbank hat kein Verfallsdatum. Das Department of Economics der Iowa State University stellt ausdrücklich klar, dass die offizielle digitale Währung der chinesischen Zentralbank kein Ablaufdatum trägt und dass sich die verbreitete Behauptung auf etwas anderes bezieht: auf digitale Konsumgutscheine, die von Lokalregierungen ausgegeben wurden und die tatsächlich verfielen.

Und genau deshalb ist das Beispiel trotzdem lehrreich, nur anders als gedacht. Die Sicherheitsforscher Frank Stajano, Ferdinando Samaria und Shuqi Zi haben 2025 im Journal of Risk and Financial Management unter dem Titel On the Nature and Security of Expiring Digital Cash ein Experiment der chinesischen Zentralbank aus dem Jahr 2020 untersucht, bei dem digitale Zahlungsmittel an 50'000 Bürger verteilt wurden, die nach wenigen Tagen ihre Gültigkeit verloren. Ihr Befund ist bemerkenswert: Verfallendes Geld ist konzeptionell kein Geld, weil niemand einen rationalen Grund hat, es als Zahlung anzunehmen.

Was in China verfiel, war also nicht die Währung, sondern eine Zahlung auf derselben Infrastruktur. Die Grenze zwischen Geld und Gutschein verlief nicht durch die Technik, sondern durch die Etikettierung. Das ist exakt die Unterscheidung, mit der auch der digitale Euro arbeitet. Wer nach dem Risiko sucht, muss also nicht nach programmierbarem Geld suchen, sondern nach dem Punkt, an dem eine auszahlende Stelle beginnt, Bedingungen an Zahlungen zu knüpfen. Diese Fähigkeit ist eingeplant, und sie ist der eigentliche Hebel.

Das Datenschutzversprechen und was daran nicht stimmt

„Wir können nicht" und „wir dürfen nicht" sind zwei völlig verschiedene Dinge, und in der Kommunikation zum digitalen Euro steht durchgehend ein Dürfen, das wie ein Können klingt.

Bei Bargeld existiert kein Datensatz. Nicht, weil es verboten wäre, einen anzulegen, sondern weil das Medium selbst keinen erzeugt. Das ist eine physikalische Eigenschaft, und deshalb ist sie stabil gegen Gesetzesänderungen. Beim digitalen Euro entstehen Transaktionsdaten zwangsläufig, sie werden bei Zahlungsdienstleistern verarbeitet, die euch identifizieren müssen. Ob und wer darauf zugreift, ist eine Frage der Rechtslage und der Zugriffsberechtigungen. Beides ist änderbar, ohne dass eine einzige Zeile der technischen Infrastruktur angefasst werden müsste.

Dass Zahlungsmetadaten das eigentlich Interessante sind, ist keine neue Erkenntnis. Wer wann wo wie viel ausgibt, ergibt ein Profil, das jede Inhaltsanalyse schlägt: Wohnort, Arbeitsweg, Gesundheitszustand, Konfession, politische Beteiligung, Beziehungsstatus. Wir haben das für Messenger bereits beschrieben, Metadaten verraten mehr als Inhalte. Für Zahlungen gilt es genauso, nur mit besserer Auflösung und ohne Interpretationsspielraum.

Der Offline-Modus ist der ehrlichste Teil des Entwurfs

Ausgerechnet die Funktion, die am meisten nach Bastellösung klingt, ist die einzige mit echter Bargeldeigenschaft. Der Wert liegt lokal auf einem Gerät, die Übertragung braucht kein Netz, es entsteht kein zentraler Datensatz. Die EZB beschreibt für diesen Fall, dass die Transaktionsdaten nur den beiden Beteiligten bekannt wären. Und deshalb gilt dort auch die Bargeldregel: Wer das Gerät verliert, verliert das Geld.

Das ist konsequent, und es ist der Punkt, an dem sich der ganze Entwurf entscheidet. Wie hoch die Obergrenze für Offline-Beträge liegt, wie viele Zahlungen ohne Netzkontakt hintereinander möglich sind, bevor ein Abgleich erzwungen wird, ob das Speichermedium herstellerunabhängig ist und ob seine Firmware quelloffen und reproduzierbar baubar ist — daran hängt, ob der Offline-Modus digitales Bargeld wird oder ein Notbehelf für den Fall, dass das Mobilfunknetz ausfällt.

Diese Details stehen im Rechtsrahmen nicht. Sie werden in der technischen Umsetzung und im Regelwerk festgelegt, also dort, wo kein Parlament mehr hinschaut und keine Abstimmung mehr stattfindet. Wenn ihr eine einzige Sache an diesem Projekt verfolgen wollt, dann diese.

Welche Risiken tatsächlich auf euch zukommen

Sortiert nach Wahrscheinlichkeit, nicht nach Dramatik.

Die Verdrängung von Bargeld durch Bequemlichkeit. Das ist das wahrscheinlichste Szenario und kommt ganz ohne Verbot aus. Wenn ein Zahlungsmittel per Gesetz überall angenommen werden muss, kostenlos ist und auf jedem Gerät funktioniert, sinkt die Bargeldnutzung von selbst. Sinkende Nutzung macht Bargeldinfrastruktur teuer, teure Infrastruktur wird abgebaut, Automaten verschwinden, Filialen schliessen, Händler stellen um. Irgendwann existiert die Wahlfreiheit nur noch auf dem Papier. Bargeld wird nicht abgeschafft, es trocknet aus.

Der Ausschluss vom Zahlungsverkehr. Wer heute sein Bankkonto verliert, hat ein schweres Problem, aber Bargeld funktioniert weiter. In einer Welt mit ausgetrocknetem Bargeld ist der Ausschluss aus dem digitalen Zahlungssystem gleichbedeutend mit dem Ausschluss aus der Wirtschaft. Dafür braucht es keine böse Absicht, ein fehlerhafter Geldwäsche-Score genügt. Solche Fälle gibt es heute schon, sie sind nur noch nicht existenziell.

Die Ausweitung der Zugriffsrechte. Nicht die EZB ist hier das Risiko, sondern der Kranz aus Steuerbehörden, Strafverfolgung und Geldwäscheaufsicht, dem der Zugriff auf Zahlungsdaten bei den Dienstleistern eingeräumt werden kann. Jede Erweiterung wird einzeln begründet und einzeln als verhältnismässig verteidigt. Dasselbe Muster liess sich beim Digital Services Act beobachten.

Die Haltegrenze als Steuerungsinstrument. Eine Obergrenze, die die Kommission per Rechtsakt anpassen kann, ist heute ein Instrument der Finanzstabilität. Sie ist gleichzeitig ein fertiger Hebel. Negativzinsen auf Guthaben oberhalb einer Schwelle wären technisch trivial, sobald das Guthaben zentral bekannt ist.

Die nachträgliche Bedingungsknüpfung. Auf kurze Sicht das unwahrscheinlichste Szenario, auf lange das folgenreichste. Es setzt keine neue Technik voraus, sondern nur eine politische Entscheidung darüber, wer Bedingungen an Zahlungen knüpfen darf. Wer glaubt, dass so etwas nicht passiert, sollte sich ansehen, wie oft in den letzten fünf Jahren Dinge beschlossen wurden, die kurz zuvor noch als undenkbar galten.

Was ausdrücklich nicht auf dieser Liste steht: die Vorstellung, der digitale Euro werde von Beginn an als Kontrollinstrument ausgerollt. Danach sieht der Entwurf nicht aus. Das Problem ist nicht die Absicht heute, sondern die Fallhöhe morgen.

Was das mit Bitcoin zu tun hat, und was nicht

Der Unterschied zwischen beiden Systemen ist nicht die Technik, sondern die Frage, wer die Regeln ändern darf.

Bei Bitcoin liegt diese Frage bei den Nutzern, die ihre eigenen Regeln durchsetzen, indem sie eine Node betreiben. Wir haben ausführlich dargelegt, warum sich Bitcoin staatlich kaum zensieren lässt. Beim digitalen Euro liegt sie bei Kommission, Rat und Parlament, und die Haltegrenze zeigt exemplarisch, wie das in der Praxis aussieht: eine Zahl, die alle zwei Jahre neu festgesetzt wird.

Gleichzeitig ist Vorsicht vor der einfachen Gegenerzählung angebracht. Bitcoin ist nicht automatisch privat. Wer über Clearnet-Dienste kauft und eine fremde Node nutzt, hinterlässt eine mindestens so gute Datenspur, wie sie ein digitaler Euro erzeugen würde, nur eben zusätzlich öffentlich einsehbar. Wir haben das in Ist no-KYC wirklich eine Garantie für Anonymität auseinandergenommen. Wer die Kritik am digitalen Euro ernst meint, muss beim eigenen Umgang mit Bitcoin-Privacy denselben Massstab anlegen.

Was ihr tun könnt

Der Rechtsrahmen ist noch nicht endgültig. Was jetzt in den Verhandlungen festgeschrieben wird, entscheidet über die nächsten Jahrzehnte, und an ein paar Stellen lässt sich das beeinflussen oder wenigstens beobachten.

• Nutzt Bargeld weiter aktiv, auch wenn Karte bequemer ist. Die Verdrängung läuft über Nutzungsstatistiken, nicht über Gesetze. Jede Bargeldzahlung ist ein Datenpunkt gegen den Abbau der Infrastruktur.
• Prüft im endgültigen Verordnungstext, ob das Verbot programmierbaren Geldes als eigener, verbindlicher Absatz in einem Artikel steht und nicht nur in der Begründung oder in Erwägungsgründen, die rechtlich schwächer wiegen.
• Achtet darauf, wie eng „bedingte Zahlung" definiert wird und vor allem, wer die Bedingung setzen darf: nur der Zahlende, oder auch eine auszahlende Stelle.
• Verfolgt die Offline-Obergrenze und die Spezifikation des Speichermediums. Fordert offengelegte Firmware, sobald konkrete Geräte diskutiert werden.
• Fragt bei euren Abgeordneten nach, ob die Haltegrenze per Gesetz oder per Kommissionsrechtsakt festgelegt wird. Das ist eine konkrete, beantwortbare Frage, und die Antwort sagt viel.
• Verlangt eine ausdrückliche Versorgungspflicht für Bargeld, nicht nur eine Annahmepflicht. Ohne garantierte Verfügbarkeit ist Wahlfreiheit rhetorisch.
• Und verbreitet keine falschen Argumente. Der Verweis auf den angeblich verfallenden digitalen Yuan diskreditiert die berechtigte Kritik, sobald ihn jemand nachprüft.

Fazit: Der digitale Euro ist so sicher wie der Satz, der ihn begrenzt

Der digitale Euro ist kein Überwachungsprojekt, und wer ihn als solches bezeichnet, macht es sich zu leicht. Er ist etwas Unangenehmeres: ein System, dessen Datenschutz und dessen Nicht-Programmierbarkeit aus Paragrafen bestehen statt aus Physik.

Die Fähigkeit, Bedingungen an Zahlungen zu knüpfen, wird gebaut. Die Transaktionsdaten entstehen. Die Haltegrenze ist per Verwaltungsakt änderbar. Alles, was zwischen dieser Infrastruktur und ihrer problematischen Nutzung steht, sind Sätze in einer Verordnung, die im selben Verfahren geändert werden kann, in dem sie beschlossen wurde. Wie belastbar dieses Verfahren ist, hat das Jahr 2026 mehrfach vorgeführt.

Bei Bargeld hängt eure Freiheit an nichts. Kein Gesetz muss sie schützen, weil das Medium sie nicht preisgeben kann. Diesen Unterschied solltet ihr kennen, bevor 2029 die erste digitale Zahlung läuft — und ihn nicht mit dem Argument abtun, dass heute ja niemand etwas Böses vorhat. Das ist noch nie die Frage gewesen. Wer daraus die grundsätzlichere Konsequenz ziehen will, findet unsere Position im Beitrag Warum die EU sterben muss, damit Europa leben kann.

Quellen und weiterführende Links

• Verordnungsvorschlag COM(2023) 369 zur Einführung des digitalen Euro, EUR-Lex
• Verfahrensstand im Legislative Train des Europäischen Parlaments
• Projektseite der Europäischen Zentralbank zum digitalen Euro
• Häufig gestellte Fragen zum digitalen Euro, EZB
• Bericht zur Abstimmung im Wirtschafts- und Währungsausschuss vom 23. Juni 2026
• Norbert Häring: Der „nicht-programmierbare" digitale Euro ist eine Mogelpackung
• Stajano, Samaria, Zi: On the Nature and Security of Expiring Digital Cash, Journal of Risk and Financial Management 2025
• Iowa State University, Department of Economics: Zum angeblichen Verfallsdatum des digitalen Yuan

Stand: 8. August 2026. Der Rechtsrahmen ist noch nicht endgültig verabschiedet. Die Angaben beziehen sich auf den Kommissionsvorschlag COM(2023) 369, den Ausschussbeschluss vom 23. Juni 2026 und die Verhandlungsposition des Rates von Dezember 2025.

The post Digitaler Euro: ein Versprechen ist kein Protokoll appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Ein Wort vorab

Dieser Artikel ist anders als das meiste, was ihr sonst hier lest. Es geht nicht um GrapheneOS, nicht um eine bessere Linux-Distribution, nicht um die nächste Bitcoin-Node. Es geht um eine Meinung — und um eine Schlussfolgerung, die sich aus lauter einzelnen Beobachtungen zusammensetzt, die wir hier über Monate dokumentiert haben. Über die Chatkontrolle. Über die Altersverifikation. Über den digitalen Euro. Über Vermögensregister und Vorratsdaten.

Nimmt man diese Beobachtungen einzeln, wirkt jede für sich verkraftbar. Legt man sie nebeneinander, ergibt sich ein Bild. Und dieses Bild führt in dystopische Zeiten — in eine Welt, die man seinen Kindern nicht zumuten will. Eine Welt, in der jede Nachricht gescannt, jede Zahlung protokolliert, jeder Ausweis verlangt und jedes Vermögen erfasst wird. Nicht von einer fremden Diktatur, sondern von einer Institution, die vorgibt, uns zu beschützen.

Die These dieses Textes ist unbequem: Die Europäische Union, so wie sie heute funktioniert, ist zu einem Apparat geworden, für den Demokratie ein Fremdwort ist. Nicht Europa. Europa — der Kontinent, die Völker, die Kultur, die Idee eines freien Zusammenlebens — ist das Wertvollste, was wir haben. Aber der bürokratische Überbau, der sich diesen Namen angeeignet hat, arbeitet zunehmend gegen genau das, was er zu vertreten behauptet. Und deshalb, so die Zuspitzung im Titel, muss diese EU in ihrer jetzigen Form sterben, damit Europa leben kann.

Ihr müsst das nicht teilen. Aber lest, was folgt — und urteilt selbst.

Das Prinzip Juncker: Schritt für Schritt, bis es kein Zurück mehr gibt

Es gibt ein Zitat, das wie kein zweites die Methode beschreibt, mit der in Brüssel Politik gemacht wird. Es stammt vom langjährigen Kommissionspräsidenten Jean-Claude Juncker, und es steht schwarz auf weiss im Spiegel 52/1999:

Man muss fair sein: Juncker hat dieses Zitat später als kritisch gemeint verteidigt — als Beschreibung eines Missstands, nicht als Programm. Doch genau hier liegt der Punkt: Ob Juncker es als Programm meinte oder als Diagnose — die Praxis der EU sieht Jahr für Jahr genau so aus. Ein Vorschlag wird "in den Raum gestellt". Man wartet ab. Regt sich Widerstand, zieht man zurück, benennt um, verpackt neu. Regt sich keiner, macht man weiter. Schritt für Schritt.

Derselbe Juncker prägte auf dem Höhepunkt der Griechenland-Krise den Satz, es könne "keine demokratische Wahl gegen die europäischen Verträge geben". Man lasse sich das auf der Zunge zergehen: Ein gewähltes Volk trifft eine Entscheidung — und die höchste Ebene der EU erklärt, dass diese Entscheidung an den Verträgen nichts ändere. Und derselbe Mann formulierte in der Euro-Krise jenen berühmten Satz, den man kaum überbieten kann: "Wenn es ernst wird, muss man lügen."

Wenn ein einzelner Politiker einmal so etwas sagt, ist das ein Ausrutscher. Wenn diese Sätze aber die Methode beschreiben, nach der ein ganzer Kontinent regiert wird, dann haben wir ein Problem. Und genau dieses Muster — beschliessen, abwarten, weitermachen — zieht sich durch alle Vorgänge, die dieser Artikel behandelt.

Es ist das Prinzip aus George Orwells 1984: nicht der eine grosse Knall, sondern die schleichende Gewöhnung. Die langsame Verschiebung dessen, was normal ist. Big Brother kommt nicht mit Getöse. Er kommt mit einem Gesetzentwurf, den kaum jemand liest, mit einer Übergangsregelung, die niemand hinterfragt, mit einer App, die man ja "freiwillig" nutzt.

Die Chatkontrolle: Neusprech in Reinkultur

Kein Vorhaben zeigt das Prinzip Juncker so deutlich wie die Chatkontrolle — offiziell die CSA-Verordnung zur Bekämpfung von sexuellem Kindesmissbrauch. Der Name ist Programm: Wer könnte gegen den Schutz von Kindern sein? Genau darin liegt die Perfidie. Denn hinter dem edlen Etikett verbirgt sich der Versuch, jede private Nachricht in Europa noch vor der Verschlüsselung durchsuchen zu lassen — das sogenannte Client-Side-Scanning.

Der Begriff "Chatkontrolle" stammt übrigens nicht von der EU. Er wurde vom ehemaligen Europaabgeordneten und Datenschützer Patrick Breyer geprägt, der seit Jahren vor diesem Vorhaben warnt. Die EU selbst spricht lieber von "Aufdeckungsanordnungen" und "Kinderschutz". Das ist Neusprech im Sinne Orwells: eine Sprache, die dazu dient, den Gedanken an das eigentliche Geschehen gar nicht erst aufkommen zu lassen.

Was das technisch bedeutet, haben 617 der weltweit führenden Kryptografen und Sicherheitsforscher im September 2025 in einem offenen Brief unmissverständlich erklärt: Es gebe schlicht keinen Algorithmus, der unbekanntes Missbrauchsmaterial zuverlässig und ohne eine grosse Zahl von Fehlern erkennen könne. Die Verordnung, so die Forscher, schaffe "beispiellose Möglichkeiten für Überwachung, Kontrolle und Zensur". Und sie hätten es wissen müssen, denn die Praxis liefert die Zahlen gleich mit.

Nach Angaben des Bundeskriminalamts waren im Jahr 2024 von 205.728 automatisiert weitergeleiteten Verdachtsmeldungen 99.375 strafrechtlich nicht relevant — eine Fehlerquote von rund 48 Prozent. Fast jede zweite Meldung ein Fehlalarm. Das bedeutet: Familienfotos vom Strand, ärztliche Aufnahmen, Flirts zwischen Erwachsenen, Sarkasmus zwischen Jugendlichen — all das landet potenziell bei Behörden, weil eine Maschine den Kontext nicht versteht. Es ist die Orwellsche Gedankenpolizei in Software gegossen: ein System, das Absicht unterstellt, wo keine ist, und das jeden unter Generalverdacht stellt.

Wenn "freiwillig" Dauerüberwachung bedeutet

Und hier zeigt sich das Prinzip Juncker in Aktion. Nach massivem öffentlichem Druck — getragen von Zivilgesellschaft, Fachleuten und einer blockierenden Minderheit von Staaten — strich der Rat am 26. November 2025 die verpflichtende Aufdeckung. Ein Erfolg? Ja. Aber lest genau: Gestrichen wurde die Pflicht. Geblieben ist das "freiwillige" Scannen — und eine Überprüfungsklausel, die die Pflicht jederzeit zurückbringen kann. Breyer warnt bereits, die Zwangsüberwachung solle "durch die Hintertür" zurückkehren, "getarnt, gefährlicher, umfassender als je zuvor".

Das ist das Muster. Man beschliesst etwas Radikales, wartet auf das Geschrei, zieht die schärfste Klinge zurück — und lässt die Architektur bestehen. Beim nächsten Mal fehlt die Aufregung, weil "das haben wir doch schon". Schritt für Schritt, bis es kein Zurück mehr gibt.

Wie ernst die Lage ist, zeigt die Reaktion der Anbieter. Meredith Whittaker, Chefin des Messengers Signal, hat mehrfach und unmissverständlich erklärt: "We will leave the EU market rather than undermine our privacy guarantees." Signal würde also lieber den europäischen Markt verlassen, als eine Überwachungsmaschine in seine App einzubauen. Sie nannte den Vorschlag treffend "surveillance wine in safety bottles" — Überwachungswein in Sicherheitsflaschen. Auch der verschlüsselte Mail-Anbieter Tuta kündigte Klage an. Wenn die vertrauenswürdigsten Anbieter sicherer Kommunikation lieber gehen als bleiben, sollte das jedem zu denken geben.

Wer treibt das eigentlich an?

Besonders bitter wird es, wenn man fragt, wer hinter dieser Gesetzgebung steht. Recherchen von Follow the Money und EDRi haben ein Geflecht offengelegt, in dem die Organisation Thorn — mitgegründet vom Hollywood-Schauspieler Ashton Kutcher — eine tragende Rolle spielt. Thorn kämpft nicht nur gegen Missbrauch, sondern verkauft zugleich die Scan-Software, die eine solche Verordnung nötig machen würde. Im EU-Transparenzregister ist die Organisation als Wohltätigkeit eingetragen. Innenkommissarin Ylva Johansson schrieb der Thorn-Chefin kurz vor Veröffentlichung des Entwurfs vertraulich: "We have shared many moments on the journey to this proposal."

Man stelle sich das vor: Eine Firma, die von einem Gesetz finanziell profitieren würde, sitzt bei der Entstehung dieses Gesetzes mit am Tisch. Und das Ganze läuft unter der Flagge des Kinderschutzes. Das ist kein Verschwörungsgerücht, das sind dokumentierte Vorgänge. Es ist der Vorwand in Reinform: Ein unangreifbares Ziel wird vorgeschoben, um eine Infrastruktur zu errichten, die mit dem Ziel nur am Rande zu tun hat.

Pfizergate: Manche sind gleicher als andere

In Orwells Farm der Tiere verkünden die Schweine am Ende jenen Satz, der die ganze Verlogenheit auf den Punkt bringt: "Alle Tiere sind gleich, aber manche Tiere sind gleicher." Wenn man einen einzigen Vorgang bräuchte, um diesen Satz auf die heutige EU anzuwenden, dann diesen.

Während der Corona-Pandemie verhandelte Kommissionspräsidentin Ursula von der Leyen persönlich per SMS mit dem Chef des Pharmakonzerns Pfizer, Albert Bourla, über Impfstoffverträge — über bis zu 1,8 Milliarden Dosen im Wert von rund 35 Milliarden Euro. Als die New York Times Einsicht in diese Nachrichten verlangte, geschah etwas Bemerkenswertes: Die Kommission konnte die SMS nicht vorlegen. Sie existierten angeblich nicht mehr, seien nicht "archivierungswürdig" gewesen.

Das Gericht der Europäischen Union sah das anders. Am 14. Mai 2025 annullierte es die Weigerung der Kommission — auf ganzer Linie. Die Begründung ist vernichtend: Die Kommission habe keine plausible Erklärung geliefert, warum sie die Dokumente nicht besitze, und damit gegen den Grundsatz der guten Verwaltung verstossen. Die Kommission legte nicht einmal Berufung ein — die Frist verstrich, das Urteil wurde rechtskräftig.

Bleiben wir fair und präzise: Gerichtlich festgestellt ist ein Transparenzbruch, nicht Korruption. Ob die SMS bewusst gelöscht wurden, um etwas zu verschleiern, ist ein Vorwurf, den die Europäische Staatsanwaltschaft weiter untersucht, aber nicht bewiesen. Doch der Kern bleibt ungeheuerlich: Die höchste Repräsentantin der EU handelt einen der grössten Beschaffungsverträge der europäischen Geschichte per Handy aus — und dann sind die Nachrichten weg, und alles ist in bester Ordnung.

Man vergleiche das mit dem, was von uns verlangt wird. Der normale Bürger soll bald jede Nachricht scannen lassen (Chatkontrolle), sein gesamtes Vermögen erfassen lassen (dazu gleich mehr), seinen Ausweis vorzeigen, um ins Netz zu dürfen (Altersverifikation). Totale Transparenz für die Bürger, Aktenvernichtung an der Spitze. Manche Tiere sind eben gleicher.

Qatargate: Koffer voller Geld — während sie euer Bargeld an der Grenze zählen

Und dann ist da noch der Moment, in dem die Farm der Tiere zur Realsatire wird. Seit dem 3. Juni 2021 gilt in der gesamten EU eine verschärfte Regel: Wer 10.000 Euro oder mehr über eine EU-Aussengrenze bringt, muss das anmelden. Neuerdings zählt sogar Gold ab einem Feingehalt von 99,5 Prozent als "Bargeld". Der Bürger, der sein eigenes, versteuertes Geld transportiert, steht unter Generalverdacht der Geldwäsche und Terrorfinanzierung. Der Zoll darf schon bei Beträgen unter 10.000 Euro tätig werden, wenn ihm etwas verdächtig vorkommt.

Und was passiert derweil im Herzen dieser Institution? Im Dezember 2022 flog der grösste Korruptionsskandal in der Geschichte des EU-Parlaments auf — später bekannt als Qatargate. Bei Razzien in Brüssel stellten die Ermittler insgesamt rund 1,5 Millionen Euro Bargeld sicher. Bei der damaligen Vizepräsidentin des Parlaments, Eva Kaili, fanden die Fahnder 600.000 Euro in Taschen in ihrer Wohnung. Ihr Vater wurde mit einem Koffer voller Geld erwischt. Das Geld soll, so die Ermittler, aus Katar geflossen sein — als Gegenleistung für wohlwollende Einflussnahme im Parlament.

Man muss sich diese Szene bildlich vorstellen, um die ganze Doppelmoral zu erfassen: Ein Kontinent, der seinen Bürgern vorschreibt, jeden Fünfhunderter über einer bestimmten Summe an der Grenze zu deklarieren, in dessen Parlamentsführung aber Koffer und Taschen voller ausländischem Bargeld kursieren. LobbyControl brachte es auf den Punkt: Das Parlament rühmt sich seiner vorbildlichen Transparenzregeln — aber die schönsten Regeln nützen nichts, wenn ihre Einhaltung nicht kontrolliert und ihre Verletzung nicht sanktioniert wird. Die Kontrolle der Abgeordneten liegt weitgehend bei den Abgeordneten selbst. Selbstkontrolle, die an ihre Grenzen gerät.

Transparenz für die Bürger, Immunität und Selbstkontrolle für die eigene Kaste. Das ist zweigleisig. Das ist zweierlei Mass. Und es ist kein Einzelfall, sondern System.

Der digitale Euro: "Nicht programmierbar" — eine Mogelpackung

Wenn die Chatkontrolle unsere Worte lesen will, dann zielt der digitale Euro auf etwas womöglich noch Intimeres: unser Geld — und damit unser gesamtes Verhalten. Denn Geld ist geronnene Freiheit. Wer kontrolliert, wofür ihr euer Geld ausgeben dürft, kontrolliert euer Leben.

Zunächst die Fakten, nüchtern: Die Europäische Zentralbank hat Ende Oktober 2025 die nächste Projektphase für den digitalen Euro beschlossen. Eine erste Ausgabe wird frühestens 2029 erwartet, sofern die EU-Gesetzgeber 2026 grünes Licht geben. Der ECON-Ausschuss des Parlaments hat im Juni 2026 seine Verhandlungsposition angenommen. Diskutiert werden Haltelimits zwischen 500 und 3.000 Euro pro Person, unverzinst. Die EZB betont bei jeder Gelegenheit, das Bargeld bleibe erhalten und die Nutzung sei freiwillig.

Und hier kommt der entscheidende Punkt — und zwar der sachlich präziseste. Die EZB verspricht, der digitale Euro werde "niemals programmierbares Geld" sein. Das klingt beruhigend. Aber der Wirtschaftsjournalist Norbert Häring hat den Trick entlarvt: Es handelt sich um eine Mogelpackung. Ausgeschlossen wird nämlich nur programmierbares Geld — also Guthaben mit Verfallsdatum oder Zweckbindung. Was aber ausdrücklich vorgesehen ist, sind programmierbare Zahlungen: bedingte Transaktionen, die an Regeln geknüpft werden können.

Der Unterschied ist ein Wortspiel — und ein Abgrund. Denn die technische Infrastruktur für bedingte Zahlungen ist genau die Infrastruktur, die man bräuchte, um Verhalten zu steuern: ein CO2-Budget, das an der Zapfsäule automatisch greift. Ein Sozialpunktesystem, das bestimmte Käufe blockiert. Eine Leistung, die nur für "genehmigte" Waren ausgegeben werden darf. Nichts davon ist heute geplant. Aber die Schienen werden verlegt. Und wer die Schienen legt, entscheidet später allein, welche Züge darauf fahren.

Das ist wieder Neusprech: "nicht programmierbar" als beruhigende Formel, während im Kleingedruckten das Gegenteil steht. Und es ist wieder das Prinzip Juncker: Man baut die Fähigkeit auf, verspricht, sie nie zu nutzen — und wartet ab. Selbst die EZB räumt ein, dass digitales Zentralbankgeld datenreicher bleibt als physisches Bargeld. Bargeld ist anonym. Der digitale Euro ist es strukturell nicht — egal, welche Datenschutzversprechen man ihm heute umhängt.

Genau deshalb ist selbstverwahrtes, dezentrales Geld wie Bitcoin keine Spielerei, sondern eine Notwendigkeit. Es ist die einzige Form von Geld, die keiner zentralen Stelle die Macht gibt, eure Zahlungen zu bedingen, zu limitieren oder abzuschalten.

Das Vermögensregister: der gläserne Bürger

Bleiben wir beim Geld — genauer: bei eurem Besitz. Hier ist Ehrlichkeit besonders wichtig, denn zu diesem Thema kursiert viel Panik, die den berechtigten Kern beschädigt. Also klipp und klar: Ein zentrales EU-Vermögensregister existiert nicht. Es ist nicht beschlossen. Wer das Gegenteil behauptet, liefert der Gegenseite die Munition, alles als Verschwörungstheorie abzutun. Das Thema ist zu wichtig, um es mit Übertreibung zu verspielen.

Was es gibt, ist Folgendes — und das ist beunruhigend genug. Das Europäische Parlament hat eine Machbarkeitsstudie in Auftrag gegeben, die 2024 vorgelegt wurde. Sie prüft, wie man Vermögen europaweit erfassen könnte, und skizziert drei Szenarien — bis hin zu einem zentralen EU-Register. Erfasst werden sollen in den Überlegungen nicht nur Bankkonten, sondern Immobilien, Unternehmensbeteiligungen, Fahrzeuge, Boote, Flugzeuge, Krypto-Werte, Gold und Rohstoffe bis hin zu Kunstwerken — im Gespräch war eine Schwelle ab 200.000 Euro. Parallel ist seit dem 1. Juli 2025 die neue Anti-Geldwäsche-Behörde AMLA mit Sitz in Frankfurt operativ, die bestehende Konten- und Eigentümerregister vernetzen soll.

Die Kommission beteuert, sie habe keinerlei Absicht, eine zentrale Vermögensdatenbank aufzubauen (ungefähr genau so, wie man keine Absichten hatte, eine Mauer zu bauen). Und die Studie selbst hält ein zentrales Register für rechtlich heikel. Gut. Aber warum lässt man dann eine solche Studie überhaupt anfertigen? Warum werden die Register vernetzt? Man kennt die Antwort inzwischen: weil man die Fähigkeit aufbaut und abwartet. Der Vorwand ist auch hier fertig konfektioniert — "Kampf gegen Geldwäsche". Wer könnte dagegen sein? Doch was als Werkzeug gegen Kriminelle beginnt, endet als Werkzeug gegen alle. Der gläserne Bürger entsteht nicht durch ein Gesetz, sondern durch die geduldige Vorbereitung seiner Voraussetzungen.

Altersverifikation und eIDAS: das Ende der Anonymität

Wir haben das Thema hier bereits ausführlich behandelt: Die Altersverifikation ist der wohl eleganteste Trick, um das freie, anonyme Internet zu beenden. Wieder mit einem edlen Vorwand — dem Schutz von Kindern vor pornografischen Inhalten.

Die EU-Kommission hat eine eigene Age-Verification-App entwickeln lassen. Im April 2026 verkündete von der Leyen deren "technische Bereitschaft"; die Verteilung in den Pilotländern läuft. Und das Entscheidende: Diese App baut auf denselben Standards auf wie die European Digital Identity Wallet (EUDI-Wallet), die nach der eIDAS-2.0-Verordnung bis Ende 2026 in allen Mitgliedstaaten verfügbar sein muss. Der Ausweis fürs Internet, sozusagen.

Offiziell verspricht man, das Ganze sei datensparsam und anonym — die Plattform erhalte nur ein "Ja" oder "Nein". Doch die Bürgerrechtsorganisationen EDRi und EFF warnen vor dem klassischen "Mission Creep": Heute nur für Pornografie und 18+, morgen für 16, 13, für "jugendgefährdende" Inhalte, für kontroverse Meinungen. Die Infrastruktur, einmal etabliert, lässt sich beliebig ausweiten. Sogar die deutsche Bundesdatenschutzbeauftragte fürchtet eine "weitgehende Abschaffung der Anonymität im Netz".

Und Anonymität ist kein Luxus für Kriminelle. Sie ist die Voraussetzung dafür, dass ein Whistleblower Missstände melden kann, dass eine Frau in einer Notlage Rat sucht, dass ein politisch Verfolgter kommuniziert. Wer die Anonymität abschafft, schafft die Freiheit ab, unbeobachtet zu denken und zu suchen. Es ist Orwells Big Brother, diesmal nicht am Fernseher, sondern an jeder Login-Maske.

Und wenn die Bürger ausweichen? Das VPN-Verbot als nächster Schritt

Hier zeigt sich die innere Logik des Überwachungsdenkens in Reinform — und ihre ganze Absurdität. Kaum ist die Altersverifikation da, stellt sich die Frage: Was, wenn die Leute sie einfach umgehen? Mit einem VPN, einem verschlüsselten Tunnel, der die eigene Herkunft verschleiert, ist das trivial. In Grossbritannien schossen die VPN-Downloads nach Einführung der dortigen Alterskontrolle um bis zu 1.800 Prozent nach oben. Die Menschen wichen aus, sofort und massenhaft.

Und prompt geriet das Werkzeug des Ausweichens ins Visier. EU-Vizekommissionspräsidentin Henna Virkkunen erklärte bei der Vorstellung der Altersverifikation, man müsse verhindern, dass Schutzmassnahmen mit VPNs umgangen würden, und werde sich mit solchen "risikoreichen Diensten" befassen — wie genau, konnte sie nicht erklären. Der Wissenschaftliche Dienst des EU-Parlaments stufte VPNs in einer Analyse als Gefahr für den Jugendschutz ein und nannte sie eine "Regelungslücke, die geschlossen werden muss". Im Raum stehen Ideen wie eine Altersprüfung für VPN-Anbieter — man müsste also seinen Ausweis vorzeigen, um ein Anonymisierungswerkzeug nutzen zu dürfen.

An dieser Stelle die notwendige Ehrlichkeit, denn hier wird viel übertrieben: Ein beschlossenes EU-VPN-Verbot gibt es nicht. Es existiert kein Gesetz und kein Legislativvorschlag dafür; entsprechende Behauptungen gehen über die Faktenlage hinaus, und Virkkunen ruderte später zurück, es gehe nicht um ein Verbot. Dänemark nahm einen eigenen Anlauf im Dezember 2025 nach öffentlicher Kritik wieder zurück. Es sind bisher politische Signale, ein Hintergrundpapier, eine unverbindliche Entschliessung — nicht mehr. Wer von einem fertigen Verbot spricht, hat unrecht.

Aber genau deshalb greift hier wieder das Prinzip Juncker: Man stellt die Idee in den Raum, wartet auf das Geschrei, rudert zurück — und lässt den Gedanken reifen. Und der Gedanke selbst ist schlicht hirnrissig, aus drei Gründen. Erstens ist er selbstzerstörerisch: Um zu verhindern, dass ein paar Jugendliche eine Sperre umgehen, müsste man das Anonymisierungswerkzeug ausweispflichtig machen — und zerstört damit genau die Anonymität, die der einzige Sinn eines VPN ist. Man würde die Anonymität von Millionen Erwachsenen opfern, um theoretisch einige Minderjährige zu bremsen. Zweitens ist er technisch naiv: Ein VPN ist nur ein verschlüsselter Tunnel. Wer ein Spiel installieren kann, kann sich für drei Euro im Monat einen eigenen WireGuard-Server auf einem beliebigen Mietserver aufsetzen — komplett ausserhalb jeder Anbieter-Regulierung. Getroffen werden nur die Gutwilligen, die legalen Nutzer, die Unternehmen im Homeoffice; die Umgehung bleibt für jeden halbwegs Versierten trivial. Drittens ist er entlarvend: VPN-Beschränkungen sind das Markenzeichen autoritärer Staaten — China, Russland, Iran. Wenn die EU auch nur laut darüber nachdenkt, den Zugang zu Verschlüsselung an einen Ausweis zu knüpfen, stellt sie sich in genau diese Reihe. Und sie verrät damit, worum es in Wahrheit nie ging: nicht um Kinderschutz, sondern um Kontrolle. Denn Kinderschutz liesse sich über die Geräte der Eltern regeln — ganz ohne die Anonymität der gesamten erwachsenen Bevölkerung zu schleifen.

Es ist Orwells Neusprech, wieder einmal: Das Werkzeug, das Bürger vor Überwachung schützt, wird zum "Schlupfloch" umgedeutet, das man "schliessen" muss. Wer die Sprache so dreht, hat die Freiheit schon zum Problem erklärt.

Der Digital Services Act: die Wächter der erlaubten Meinung

Wenn Chatkontrolle und Altersverifikation regeln, wer wie kommuniziert, dann regelt der Digital Services Act (DSA), was gesagt werden darf. Offiziell ist der DSA ein Gesetz für mehr Transparenz und Verantwortung grosser Plattformen wie Facebook, TikTok oder X — gegen illegale Inhalte, Betrug und Desinformation. Das klingt vernünftig, und ein Teil davon ist es auch. Doch im Detail steckt ein Mechanismus, der zum wohl umstrittensten Instrument der europäischen Netzpolitik geworden ist: die sogenannten Trusted Flagger — auf Deutsch "vertrauenswürdige Hinweisgeber".

Nach Artikel 22 des DSA können bestimmte Organisationen von einer nationalen Behörde — in Deutschland der Bundesnetzagentur — als Trusted Flagger zertifiziert werden. Melden sie einen Inhalt, muss die Plattform diese Meldung vorrangig und beschleunigt bearbeiten. Man muss hier fair bleiben: Diese Stellen haben selbst keine Löschbefugnis; die Entscheidung trifft am Ende die Plattform. Verteidiger des DSA betonen zu Recht, dass die Trusted Flagger juristisch eher "zahnlose Papiertiger" seien und Meinungsfreiheit nicht bedeute, auf jeder privaten Plattform unbegrenzte Reichweite zu haben.

Und doch liegt genau hier das Problem. Wie der Verfassungsblog analysiert, entsteht bereits durch die bevorzugte Behandlung ein Gefährdungspotenzial für die Meinungsfreiheit: Eine Plattform, die von einer staatlich lizenzierten und oft auch staatlich finanzierten Meldestelle einen Hinweis erhält, wird im Zweifel eher löschen — schon um mögliche Sanktionen zu vermeiden. Das ist der klassische Chilling Effect, das Overblocking: Im Zweifel wird weggeklickt, was Ärger machen könnte. Und "im Zweifel" trifft oft legale, nur unbequeme Meinungen.

Die entscheidende Frage lautet: Wer bestimmt, was "Desinformation" ist? Was ein "systemisches Risiko"? Wenn eine staatlich anerkannte und mit öffentlichen Geldern geförderte Organisation darüber wacht, welche Meinungen als schädlich gelten, ist die Grenze zur politischen Einflussnahme schnell überschritten. Ein Beispiel, das für Diskussionen sorgt: Die Organisation HateAid wurde im Juni 2025 als Trusted Flagger zertifiziert und hatte bis dahin nach Angaben von Kritikern Millionen an öffentlichen Fördermitteln erhalten. Ob die einzelnen Vorwürfe gegen ihre Meldepraxis zutreffen, ist umstritten — der Kern des Problems bleibt aber unabhängig vom Einzelfall bestehen: Sobald der Staat mitfinanziert, wer im Netz was melden darf, verschwimmt die Grenze zwischen Rechtsdurchsetzung und Meinungslenkung.

Auch hier greift das Neusprech. Wenn Befürworter davon sprechen, Trusted Flagger leisteten einen Beitrag zur "Demokratiehygiene", dann sollte man hellhörig werden. Denn wer entscheidet, was "hygienisch" ist und was nicht? Begriffe wie "Desinformation", "Hass" und "Delegitimierung" sind dehnbar — und genau diese Dehnbarkeit macht sie zum idealen Werkzeug. Es ist Orwells Wahrheitsministerium in institutioneller Form: ein Apparat, der nicht die Wahrheit findet, sondern festlegt, welche Aussagen als wahr gelten dürfen.

Richter, Ankläger und Vollstrecker in einer Hand

Doch der Trusted Flagger ist nur die sichtbare Spitze. Das eigentliche Machtproblem des DSA liegt eine Ebene höher — und es rührt an ein Fundament jeder freien Ordnung: die Gewaltenteilung. Seit Montesquieu ruht der freiheitliche Staat auf der Trennung dreier Gewalten. Wer die Gesetze macht (Legislative), wer sie ausführt (Exekutive) und wer über ihre Einhaltung richtet (Judikative), soll nicht dieselbe Instanz sein — sonst gibt es niemanden mehr, der die Macht kontrolliert. Genau diese Trennung verschwimmt beim DSA auf bedenkliche Weise.

Für die grossen Plattformen — die "Very Large Online Platforms" mit über 45 Millionen EU-Nutzern, also praktisch das gesamte öffentliche Netz — liegt die Aufsicht unmittelbar bei der EU-Kommission. Und dort ist die Kommission alles zugleich: Sie legt über Leitlinien und delegierte Rechtsakte fest, was als "systemisches Risiko" oder "Desinformation" gilt — sie setzt also die Regel. Sie eröffnet die Verfahren und ermittelt — sie ist Anklägerin, aktuell etwa gegen X, TikTok, Meta und Shein. Sie verhängt am Ende die Strafe: Bussgelder bis zu sechs Prozent des weltweiten Jahresumsatzes — sie ist Richterin und Vollstreckerin. Und sie finanziert ihre eigene Aufsicht über eine Gebühr, die sie den Beaufsichtigten selbst abverlangt — sie ist obendrein Kassiererin.

Regelsetzer, Ermittler, Richter, Vollstrecker und Finanzier in einer einzigen Behörde. Das ist keine Gewaltenteilung mehr, das ist Gewaltenbündelung. Und die Drohkulisse ist real: Sechs Prozent des Weltumsatzes sind für einen Konzern existenzbedrohend. Eine Plattform, die zwischen "eine unbequeme, aber legale Meinung stehen lassen" und "ein Milliarden-Bussgeld riskieren" wählen muss, entscheidet sich im Zweifel für die Löschung. So wird aus einer Institution, die offiziell nur Transparenz durchsetzt, faktisch der Entscheider und Vollstrecker darüber, was im europäischen Netz gesagt werden darf. Genau das ist der Punkt: Die EU macht sich hier zugleich zum Gesetzgeber, zum Ausführenden und zum Richter der Meinungsregulierung — und schleift damit die Grenze, die den Bürger vor der geballten Staatsmacht schützen soll.

Ein verbreiteter Irrtum sei an dieser Stelle ausgeräumt: Die berüchtigten Uploadfilter sind nicht Teil des DSA. Sie stammen aus Artikel 17 der Urheberrechtsrichtlinie von 2019 — einem eigenen Gesetz, das wir weiter unten behandeln. Dass beide oft in einen Topf geworfen werden, hat einen nachvollziehbaren Grund: Beide verlagern die Kontrolle über Inhalte weg vom Richter, hin zu automatisierten Systemen und privaten Plattformen unter staatlichem Druck. Der Mechanismus ist verwandt — die Rechtsgrundlage ist es nicht.

Fairerweise gehört die andere Seite dazu: Hass, Gewaltaufrufe und illegale Inhalte sind reale Probleme, Plattformen behalten formal das letzte Wort, und die Justiz bleibt die letzte Instanz — sie funktioniert auch. Als die Kommission die DSA-Aufsichtsgebühren zu nachlässig festlegte, kassierte das Gericht der EU 2025 ihre Bescheide wegen eines Formfehlers. Der DSA gibt Nutzern zudem neue Rechte gegen die Willkür der Konzerne — ein Beschwerde- und Schlichtungssystem gegen ungerechtfertigte Löschungen. Bemerkenswert dabei: Im ersten Halbjahr 2025 erfolgten 99 Prozent der Eingriffe gar nicht wegen des DSA, sondern wegen der oft schwammigen Hausregeln der Plattformen selbst. Das Problem ist also nicht der DSA allein, sondern die Kombination: private Konzerne mit vagen Regeln, staatlich finanzierte Melder und eine Kommission mit der Bussgeld-Keule. Doch genau in dieser Bündelung liegt die Gefahr. Eine Ordnung, in der legale, nur missliebige Äusserungen unter gebündeltem Druck vorsorglich verschwinden und die Gerichte erst Jahre später korrigieren, wenn der Chilling Effect längst gewirkt hat, ist kein Zeichen einer selbstbewussten Demokratie. Eine solche verträgt Widerspruch. Sie muss ihn nicht wegmoderieren.

Das Muster der Vorwände

Man könnte all das für eine Reihe unglücklicher Einzelfälle halten. Aber es ist ein Muster. Immer dasselbe: ein unangreifbares Ziel — Kinderschutz, Terrorabwehr, Geldwäschebekämpfung — dient als Vorwand für den Aufbau von Überwachungs- und Kontrollstrukturen, die weit über das Ziel hinausgehen.

Die Vorratsdatenspeicherung ist das Lehrstück. Der Europäische Gerichtshof hat die anlasslose, allgemeine Speicherung von Verbindungsdaten wiederholt für rechtswidrig erklärt, zuletzt 2022 im Fall der deutschen Regelung. Und was macht die EU? Sie hält an der Idee fest, sucht neue Wege, weicht auf. In der "Going Dark"-Arbeitsgruppe — hinter verschlossenen Türen, unter Ausschluss der Zivilgesellschaft — wurden 2024 sage und schreibe 42 Empfehlungen erarbeitet, die auf Verschlüsselungs-Hintertüren und ausgeweitete Datenspeicherung hinauslaufen. Der Name selbst ist Neusprech: "Going Dark", das Dunkelwerden — als seien die Behörden blind, während sie in Wahrheit über beispiellosen Datenzugriff verfügen.

Dasselbe bei den Uploadfiltern: Mit Artikel 17 der Urheberrechtsrichtlinie wurde eine Vorabkontrolle von Inhalten eingeführt, die der EuGH 2022 zwar für zulässig erklärte — aber nur unter strengen Schutzvorkehrungen für die Meinungsfreiheit. Dasselbe bei eIDAS Artikel 45, wo Mozilla und Hunderte Sicherheitsexperten warnten, die geplanten Zertifikatsregeln würden die Sicherheit des gesamten Webs untergraben und staatliches Mitlesen ermöglichen. Und dasselbe bei der Bargeldobergrenze von 10.000 Euro, die ab Juli 2027 EU-weit gilt.

Jede dieser Massnahmen ist für sich begründbar. In Summe ergeben sie das Bild eines Kontinents, der seine Bürger lückenlos erfassen, lesen, protokollieren und kontrollieren will — Schritt für Schritt, bis es kein Zurück mehr gibt.

Zweierlei Mass: die Regeln gelten für euch, nicht für sie

Kehren wir zu Orwells Schweinen zurück. Der eigentliche Skandal ist nicht allein die Überwachung — es ist die Doppelmoral. Für den Bürger gelten eiserne Regeln; für die Kaste gelten sie flexibel oder gar nicht.

Man denke an José Manuel Barroso, den früheren Kommissionspräsidenten, der 2016 zum Chairman von Goldman Sachs International wurde — jener Bank, die eine zentrale Rolle in der Finanzkrise spielte, die Europa in die Austerität stürzte. Formal brach Barroso keine Regel; die Karenzzeit war abgelaufen. Doch eine Petition von EU-Bediensteten sammelte über 154.000 Unterschriften. Barroso ist kein Einzelfall — die Drehtür zwischen Brüsseler Amt und Konzernvorstand dreht sich munter weiter.

Man denke an die schiere Dimension des Lobbyismus in Brüssel: rund 25.000 Lobbyisten, nach Washington die zweitgrösste Konzentration der Welt. Allein die grössten Konzerne geben inzwischen über 380 Millionen Euro pro Jahr für Lobbyarbeit aus. Wer in diesem Ohr flüstert, hat Einfluss. Der Bürger flüstert nicht — er zahlt und gehorcht.

Man denke an den monatlichen Wanderzirkus des Parlaments zwischen Brüssel und Strassburg: eine sinnlose Pendelei, die den Steuerzahler nach der verlässlichsten Schätzung des Rechnungshofs rund 114 Millionen Euro im Jahr und über 20.000 Tonnen CO2 kostet — nur, weil Frankreich auf seinem Standort besteht und eine Änderung Einstimmigkeit erfordert.

Und man denke an den Umgang mit Ungarn: Im Dezember 2023 gab die Kommission rund 10,2 Milliarden Euro eingefrorene Mittel frei — ausgerechnet, kurz bevor Viktor Orban auf einem Gipfel gebraucht wurde. Das Parlament klagte dagegen und nannte es politisch motiviert. Die Kommission bestreitet einen Deal, und das Verfahren ist noch offen — der Vorwurf des zweierlei Masses bleibt Interpretation. Aber es ist eine Interpretation, die sich aufdrängt: Wo der Rechtsstaatsmechanismus als Druckmittel gegen Unbequeme dient und als Ware, wenn man etwas braucht, ist er kein Prinzip mehr, sondern Taktik.

Für uns: Chatkontrolle, Vermögensregister, Bargeldgrenzen, Ausweispflicht. Für sie: gelöschte SMS, Koffer voller Geld, Goldman-Sachs-Posten und Milliardendeals mit Handschlag. Alle Tiere sind gleich. Aber manche sind eben gleicher.

Die Folgen: ein Kontinent, der nicht mehr wächst

Bis hierher ging es um Überwachung und Doppelmoral. Doch all das geschieht nicht im luftleeren Raum. Es geschieht vor dem Hintergrund eines Kontinents, der wirtschaftlich den Anschluss verliert und dessen Gesellschaften auseinanderdriften. Und beides hängt mit der Art zusammen, wie in Brüssel regiert wird.

Beginnen wir mit den harten Zahlen. Deutschland — jahrzehntelang der Wirtschaftsmotor Europas — hat gerade das hinter sich, was es in seiner Nachkriegsgeschichte noch nie gab: drei Jahre Rezession und Stagnation in Folge. Das Bruttoinlandsprodukt schrumpfte 2023 um 0,9 Prozent, 2024 um weitere 0,5 Prozent, und 2025 kletterte es gerade eben um mickrige 0,2 Prozent — statistisch das Ende der Rezession, gefühlt ein Stillstand. Das Institut der deutschen Wirtschaft brachte es im Dezember 2025 auf den Punkt: Selbst das erwartete Mini-Wachstum von knapp einem Prozent für 2026 sei "keine wirkliche Aufschwungsqualität" — eine echte Trendwende sei nicht in Sicht. Der ganze Euroraum dümpelt bei gut einem Prozent Wachstum vor sich hin.

Das ist kein Ausrutscher, sondern ein struktureller Absturz. Man muss es nicht von EU-Kritikern hören — man kann es bei jemandem nachlesen, der der EU denkbar nahesteht: Mario Draghi, ehemaliger EZB-Chef, in seinem Bericht zur europäischen Wettbewerbsfähigkeit von 2024, in Auftrag gegeben von der Kommission selbst. Draghis Befund ist verheerend: Das Bruttoinlandsprodukt der EU liegt inzwischen rund 30 Prozent hinter dem der USA zurück — 2002 waren es erst 15 Prozent. Europa fällt seit den 2000er-Jahren immer weiter zurück, vor allem, weil es die Produktivität nicht steigert und bei Zukunftstechnologien den Anschluss verpasst hat. Draghi nennt das eine "existenzielle Herausforderung" — und warnt, dass Europa ohne drastisch besseres Wachstum bald nicht mehr in der Lage sein werde, seinen eigenen Sozialstaat zu finanzieren.

Und was empfiehlt ausgerechnet Draghi, der Insider? Unter anderem: weniger und bessere Regulierung. Man lasse das wirken. Der Kronzeuge der EU selbst diagnostiziert, dass der Regulierungsapparat, den wir in diesem Artikel Kapitel für Kapitel beschrieben haben, das Wachstum erstickt. Natürlich hat die Schwäche viele Ursachen — teure Energie, der demografische Wandel, die Konkurrenz aus China, die US-Zölle. Aber der Reflex Brüssels, auf jedes Problem mit einem neuen Gesetz, einer neuen Meldepflicht, einer neuen Kontrollbehörde zu antworten, ist ein Teil davon. Ein Kontinent, der seine Bürger scannt, ihr Vermögen katalogisiert und ihre Zahlungen bedingt, ist kein Kontinent, der Unternehmer, Erfinder und Investoren anzieht. Er ist einer, den sie verlassen.

Deindustrialisierung mit Ansage

Nirgends wird dieser Absturz greifbarer als bei jenem Konzern, der jahrzehntelang für das deutsche Wirtschaftswunder stand: Volkswagen. Der Autobauer verzeichnete 2025 den grössten Gewinneinbruch seit dem Dieselskandal — der Nettogewinn brach um fast die Hälfte ein. Nach einem ersten Abbauprogramm von rund 35.000 Stellen in Deutschland folgte 2025 die Ankündigung von konzernweit rund 50.000 gestrichenen Arbeitsplätzen bis 2030. Und im Juni 2026 berichtete das "Manager Magazin" unter Berufung auf Insider von bis zu 100.000 wegfallenden Stellen weltweit und der drohenden Schliessung von vier Werken — Hannover, Zwickau, Emden und das Audi-Werk Neckarsulm. Der Konzern bestätigte die 100.000 nicht, sprach aber von "tiefgreifenden" Veränderungen. Die Begründung des VW-Sprechers ist bezeichnend: Das Modell, "Autos in Deutschland zu entwickeln, in Europa zu produzieren und weltweit zu exportieren", funktioniere nicht mehr.

Das ist mehr als eine Firmenkrise — es ist ein Symbol. Und die Ironie ist bitter: Während Brüssel per Verordnung das Aus für den Verbrennungsmotor ab 2035 beschloss, dominiert längst China den Weltmarkt für Elektroautos. Man hat die eigene Schlüsselindustrie einer Ideologie unterworfen, ohne die industrielle Basis zu schaffen, die diese Ideologie tragen könnte. Die Politik gab das Ziel vor, den Weg dorthin überliess sie dem Markt — nur dass der Markt inzwischen in Shenzhen sitzt, nicht in Wolfsburg.

Und wo bleiben die neuen Champions, die den Verlust ausgleichen? Sie entstehen woanders. Draghi hat den Kern benannt: Der Produktivitätsrückstand Europas ist weitgehend ein Rückstand im Techsektor — Europa hat kein Google, kein Amazon, keinen globalen Techgiganten hervorgebracht. Es gibt europäische Fintechs und Startups, gewiss, doch die wirklich grossen Erfolgsgeschichten wandern nach Übersee, wo Kapital, Skalierung und schlankere Regeln locken. Statt Innovation zu ermöglichen, produziert Europa Verordnungen: DSGVO, DSA, DMA, AI Act, Lieferkettengesetz, Taxonomie. Jede einzelne mag gut gemeint sein. In Summe ergeben sie ein Klima, in dem der Gründer erst einen Compliance-Beauftragten braucht, bevor er das erste Produkt baut. Bürokratie ohne Ende — und am Ende wundert man sich, dass die Klügsten ihre Firmen nicht hier gründen.

Eine gespaltene Gesellschaft — und eine Politik, die es anfeuert

Wirtschaftliche Perspektivlosigkeit bleibt nie ohne gesellschaftliche Folgen. Wenn Menschen das Gefühl haben, dass es bergab geht und niemand sie hört, wächst die Wut. Und die Zahlen sind alarmierend: Nur noch 14 Prozent der Deutschen glauben, dass es der nächsten Generation besser gehen wird als der heutigen. Vierzehn Prozent. Ein Land, das den Glauben an die eigene Zukunft verloren hat.

Das Vertrauen in die Institutionen — die Bundesregierung, die EU — ist auf einem Tiefpunkt, und die Forscher benennen die Ursachen klar: die wirtschaftliche Rezession und die zunehmende Polarisierung, in deren Folge sich viele Bürger nicht mehr repräsentiert fühlen. Diese Polarisierung ist messbar: Studien zeigen, dass die gesellschaftliche und politische Spaltung in Europa seit 2019 weiter zunimmt. Sogar der Europäische Wirtschafts- und Sozialausschuss — ein EU-Organ — warnt vor einer "zunehmenden gesellschaftlichen Fragmentierung" und davor, dass Polarisierung, wenn sie in Feindseligkeit umschlägt, "die Grundfesten unserer Demokratien" bedrohe.

Und hier schliesst sich der Kreis. Eine Politik, die nicht liefert, die Wohlstand verwaltet statt schafft, die den Bürger überwacht statt ihm zu vertrauen, treibt genau jene Spaltung voran, über die sie sich dann öffentlich empört. Man baut Überwachungsinfrastruktur gegen die eigene Bevölkerung, weil man sie zunehmend als Risiko begreift — und wundert sich, dass diese Bevölkerung das Vertrauen verliert. Man schürt mit immer neuen Verboten und Belehrungen den Frust — und beklagt dann den "Rechtsruck" und den "Extremismus", den man selbst mitgezüchtet hat. Wer die Mitte der Gesellschaft dauerhaft bevormundet und ihr das Gefühl gibt, dass ihre Sorgen nicht zählen, muss sich nicht wundern, wenn sie an die Ränder wandert.

Das ist die eigentliche Tragödie. Die Werkzeuge, die angeblich Sicherheit und Zusammenhalt schaffen sollen — Chatkontrolle, digitaler Euro, Vermögensregister —, bewirken das Gegenteil: Sie zerstören Vertrauen, ersticken Wachstum und vertiefen die Gräben. In Orwells Welt hält die Angst das System zusammen. In unserer droht die Angst, es zu zerreissen.

Die Bar, in die niemand freiwillig ginge

Das Problem an all dem ist, dass es so schwer zu fassen ist. Das Digitale ist schwammig, unsichtbar, abstrakt. Ein Algorithmus, der Nachrichten scannt, ein Haltelimit im digitalen Euro, ein Trusted Flagger — das sind Begriffe, unter denen sich kaum jemand etwas Konkretes vorstellt. Also übersetzen wir es einmal in die echte Welt. Stellt euch vor, all das gälte nicht im Netz, sondern an einem ganz normalen Freitagabend, wenn ihr euch mit ein paar Freunden auf ein Bier trefft.

Ihr kommt an der Bar an. Bevor ihr hinein dürft, müsst ihr an der Tür euren Ausweis vorzeigen — und es wird ein Gesichtsscan gemacht, eure biometrischen Daten werden erfasst und gespeichert. Das ist die Altersverifikation, die digitale Identität an der Eingangstür.

Ihr setzt euch an einen Tisch. In der Mitte steht ein Mikrofon. Es nimmt alles auf, jedes Wort, jeden Witz, jede hitzige politische Diskussion — und eine künstliche Intelligenz hört live mit und wertet aus, noch während ihr redet. Das ist die Chatkontrolle: Jede Äusserung wird durchleuchtet, bevor sie überhaupt bei eurem Gegenüber ankommt.

An den Nebentischen sitzen unauffällige Gäste. Sie sehen aus wie ihr, aber es sind zertifizierte Spitzel — für den Fall, dass die KI etwas übersieht, hören sie mit und melden, was ihnen missfällt. Das sind die Trusted Flagger: staatlich anerkannte Denunzianten, deren Meldung bevorzugt behandelt wird.

Sagt jetzt einer von euch etwas Falsches — eine unbequeme Meinung, einen derben Scherz —, dann steht Sekunden später die Polizei am Tisch. Ohne richterlichen Beschluss, ohne Verfahren, sofort. Und das Bemerkenswerte: Der Wirt dieser Bar hat die Hausordnung selbst geschrieben, entscheidet allein, was verboten ist, ruft die Polizei und kassiert am Ende auch noch das Bussgeld. Ankläger, Richter und Vollstrecker in einer Person. Das ist die Welt ohne Gewaltenteilung, wie sie der DSA für das Netz anlegt.

Und wenn ihr euch danach mit einem weiteren Bier beruhigen wollt? Der Barkeeper verweigert es. Ihr habt euer Limit überzogen — mehr ist heute nicht vorgesehen. Oder ihr bekommt von vornherein gar nichts, weil ihr längst geflaggt seid und euer Geld für Alkohol schlicht nicht mehr funktioniert. Das ist der digitale Euro/Franken mit seinen Haltelimits und bedingten Zahlungen: Geld, das nur noch das kauft, was erlaubt ist, und dem, der auffällt, den Dienst verweigert.

In eine solche Bar würde kein Mensch freiwillig gehen. Ihr würdet auf dem Absatz kehrtmachen, es einen Polizeistaat nennen, euch fragen, in welchem Albtraum ihr gelandet seid. Niemand würde diese Zustände auch nur eine Minute hinnehmen.

Und doch ist es exakt diese Bar, die gerade Raum für Raum im Digitalen gebaut wird. Die Chatkontrolle ist das Mikrofon. Die Altersverifikation ist die Tür. Die Trusted Flagger sind die Spitzel. Der DSA ist der Wirt, der zugleich Richter und Polizei ist. Der digitale Euro ist der Barkeeper, der euch abschneidet. Der einzige Unterschied zur Bar: Im Netz seht ihr das Mikrofon nicht auf dem Tisch, den Spitzel nicht am Nebentisch, das Limit nicht auf der Rechnung. Alles ist unsichtbar, in Code gegossen, hinter freundlichen Worten versteckt. Genau deshalb ist es so schwer zu greifen — und genau deshalb ist es so gefährlich.

Warum die EU sterben muss, damit Europa leben kann

Nun die notwendige Fairness — denn ein Argument ist nur so stark wie sein Umgang mit dem Gegenargument. Der Schutz von Kindern vor Missbrauch ist ein reales, drängendes Anliegen. Geldwäsche und Terrorfinanzierung sind reale Probleme. Die EZB hat reale Gründe, angesichts der Dominanz amerikanischer Zahlungsdienstleister über eine europäische Alternative nachzudenken. Und die EU hat Europa Jahrzehnte des Friedens, offener Grenzen und eines Binnenmarkts gebracht, von dem gerade ein Exportland wie die Schweiz mittelbar profitiert. Das alles gehört auf den Tisch.

Aber genau darum geht es. Man kann all diese legitimen Ziele verfolgen, ohne jeden Bürger unter Generalverdacht zu stellen. Man kann Kinder schützen, ohne die Verschlüsselung zu brechen. Man kann Geldwäsche bekämpfen, ohne das Vermögen jedes Einzelnen zu katalogisieren. Man kann eine europäische Währung wollen, ohne die Infrastruktur zur Verhaltenssteuerung mitzuliefern. Der Weg, den diese EU wählt, ist nicht der einzige Weg. Er ist eine Entscheidung. Und es ist immer dieselbe Entscheidung: mehr Erfassung, mehr Kontrolle, weniger Anonymität, weniger Selbstbestimmung.

Der Titel dieses Artikels ist bewusst zugespitzt. "Die EU muss sterben" heisst nicht: zurück zu Nationalismus und geschlossenen Grenzen. Es heisst: Dieser bürokratische, kontrollversessene, sich selbst über die Demokratie stellende Apparat muss sterben — damit die eigentliche europäische Idee leben kann. Die Idee eines Kontinents freier Menschen, die einander vertrauen, statt einander zu überwachen. Die Idee, dass der Staat dem Bürger dient und nicht umgekehrt. Die Idee, dass Grundrechte keine Verhandlungsmasse sind, die man Schritt für Schritt abträgt, bis es kein Zurück mehr gibt.

Orwell hat "1984" nicht als Anleitung geschrieben, sondern als Warnung. Er hat "Farm der Tiere" nicht geschrieben, damit wir uns bequem zurücklehnen, sondern damit wir die Schweine erkennen, wenn sie beginnen, auf zwei Beinen zu gehen. Die Werkzeuge, die uns bleiben, sind konkret und in unserer Hand: Verschlüsselung nutzen und verteidigen. Bargeld erhalten. Selbstverwahrtes Geld wie Bitcoin lernen und verwenden. Freie Software und dezentrale Infrastruktur aufbauen. Und laut sein — denn das Prinzip Juncker funktioniert nur, solange es "kein grosses Geschrei gibt".

Die Chatkontrolle wurde vorerst gestoppt, weil es Geschrei gab. Das ist der Beweis: Es funktioniert. Aber sie kommt zurück, getarnt und umbenannt. Wie all das andere. Wer digitale Souveränität ernst nimmt, hat keine Wahl, als wachsam zu bleiben. Nicht aus Paranoia — sondern weil man das, was man kommen sieht, seinen Kindern nicht zumuten will.

Europa ist es wert, verteidigt zu werden. Auch — und gerade — gegen die, die in seinem Namen sprechen.

Dieser Artikel ist ein Meinungsbeitrag. Wo Vorgänge gerichtlich festgestellt sind (etwa das Pfizergate-Urteil oder die EuGH-Urteile zur Vorratsdatenspeicherung), ist das kenntlich gemacht; wo es um Vorwürfe, Befürchtungen oder Interpretationen geht (etwa mögliche Korruption oder die Zukunft des Vermögensregisters), ebenso. Alle Fakten sind verlinkt — bildet euch euer eigenes Urteil.

The post Warum die EU sterben muss, damit Europa leben kann appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

• Es geht um die freiwillige „Chatkontrolle 1.0" – eine Ausnahme von den EU-Datenschutzregeln, die Anbietern wie Meta, Google oder Microsoft erlaubt, unverschlüsselte Inhalte freiwillig nach Missbrauchsdarstellungen zu durchsuchen. Ende-zu-Ende-verschlüsselte Messenger wie Signal, Threema oder Element sind ausdrücklich ausgenommen.
• Es geht nicht um die verpflichtende „Chatkontrolle 2.0" mit Client-Side-Scanning. Die steckt weiter im Trilog.

Trotzdem ist der Vorgang ein Lehrstück darüber, wie in Brüssel ein einmal gefälltes „Nein" über Verfahrenstricks in ein „Ja" verwandelt wird. Genau deshalb schauen wir hier genauer hin.

Was am 9. Juli tatsächlich passiert ist

Rein rechnerisch hat eine relative Mehrheit der Abgeordneten gegen die Verlängerung der Ausnahme gestimmt. Laut netzpolitik.org und dem früheren EU-Abgeordneten Patrick Breyer waren es 314 Gegenstimmen. Der Haken: Um den Ratsvorschlag endgültig zu begraben, wäre eine absolute Mehrheit von 361 Stimmen nötig gewesen. Diese Hürde wurde verfehlt – und damit gilt der Vorschlag als angenommen.

Anders gesagt: Nicht die Befürworter mussten eine Mehrheit organisieren, sondern die Gegner. Die Beweislast wurde umgekehrt. Wer die Überwachung stoppen wollte, musste dafür die absolute Mehrheit des gesamten Parlaments mobilisieren – mitten in der beginnenden Sommerpause, in der ein Teil der Abgeordneten gar nicht mehr anwesend war.

Ein Änderungsantrag der liberalen Renew-Fraktion, der die Ende-zu-Ende-Verschlüsselung explizit ausnimmt, ging durch. Wie das technisch sauber umgesetzt werden soll, bleibt allerdings offen. Formal ist die Sache damit noch nicht abgeschlossen: Das Parlament hat seine Position gebilligt und Änderungen verlangt, Kommission und Rat müssen abschliessend zustimmen, bevor die Regel wieder greift.

Der Verfahrenstrick im Detail: So wurde aus einem „Nein" ein „Ja"

Der eigentliche Skandal steckt nicht im Ergebnis, sondern im Weg dorthin. Kritiker aus mehreren Fraktionen sprechen von einem „Taschenspielertrick", einem „illegalen Geschäftsordnungstrick" und einem „demokratiepolitischen Foulspiel". Der Mechanismus lässt sich in drei Bausteinen erklären:

1. Die Verschiebung in die „zweite Lesung". Das Dossier wurde formal in die zweite Lesung des ordentlichen Gesetzgebungsverfahrens gehoben. Und genau hier greift die entscheidende Umkehr: In der zweiten Lesung kann der Standpunkt des Rates nur noch mit einer absoluten Mehrheit von 361 der 719 Abgeordneten abgelehnt oder geändert werden. Wird diese Schwelle innerhalb der Frist nicht erreicht, gilt der Ratsstandpunkt automatisch als angenommen. Normalerweise braucht ein Gesetz eine Mehrheit dafür. Hier war es umgekehrt: Der Vorschlag war durch, solange ihm nicht 361 Abgeordnete aktiv widersprechen. Jede leere Stelle im Plenarsaal spielte damit dem Vorschlag in die Hände.

2. Eine eigens dafür erstellte Ratsstellungnahme. Damit diese zweite Lesung überhaupt ausgelöst werden konnte, brachten die EU-Staaten formell noch einmal eine Position ein – eine Stellungnahme, die von Kritikern als eigens zu diesem Zweck angefertigt beschrieben wird. Angestossen hatte das Ganze Parlamentspräsidentin Roberta Metsola, die sich Mitte Juni beim EU-Gipfel überraschend dafür einsetzte, erneut an einer Übergangslösung zu arbeiten – und sich dabei die Rückendeckung der Mitgliedstaaten und der EVP holte, nicht aber die der übrigen Fraktionen.

3. Das Dringlichkeitsverfahren und das perfekte Timing. Die EVP beantragte ein Dringlichkeitsverfahren, das den sonst zuständigen Innenausschuss (LIBE) umging. Am 7. Juli stimmte das Parlament mit 331 zu 304 Stimmen für dieses beschleunigte Verfahren. Die entscheidende Sachabstimmung wurde dann auf den 9. Juli gelegt – den letzten Sitzungstag vor der Sommerpause. An diesem Tag waren nur noch rund 600 der 719 Abgeordneten anwesend. Die Rechnung dahinter ist simpel: Wer für eine Ablehnung 361 aktive Gegenstimmen organisieren muss, während ein Teil der Kollegen schon auf dem Weg in den Urlaub ist, hat kaum eine Chance. Die fraktionslosen Abgeordneten Sibylle Berg und Martin Sonneborn hatten Metsola vorab schriftlich aufgefordert, das Dringlichkeitsverfahren gar nicht erst zuzulassen – die Geschäftsordnung sehe ein solches Verfahren in der zweiten Lesung nicht vor.

Das Ergebnis vom 9. Juli

Und genau so kam es: Änderungsanträge, die die Ratsinitiative ganz abgelehnt hätten, verfehlten gleich zu Beginn mit 314 zu 276 Stimmen bei 17 Enthaltungen die nötige absolute Mehrheit von 361 – so die Zählung von heise online und Patrick Breyer. Damit steht fest: Eine Mehrheit der tatsächlich anwesenden Abgeordneten stimmte gegen die Vorlage – und sie kam trotzdem durch. Reaktiviert wird die Chatkontrolle 1.0 damit für rund zwei Jahre, also bis etwa 2028.

Der komplette Ablauf im Zeitraffer:

1. 26. März 2026: Das Parlament lehnt die Verlängerung der freiwilligen Ausnahme ab – mit 311 Gegenstimmen zu 228 Ja-Stimmen und 92 Enthaltungen. Die Übergangsregelung läuft am 3. April 2026 aus.
2. Mitte Juni 2026: Metsola bringt das Thema beim EU-Gipfel zurück auf die Agenda.
3. Anfang Juli: Der Rat holt die Ausnahme über einen formal neuen Entwurf zurück; die EU-Staaten ermöglichen dem Parlament damit, ein drittes Mal abzustimmen.
4. 7. Juli: Das Parlament billigt mit 331 zu 304 Stimmen das Dringlichkeitsverfahren.
5. 9. Juli: Die Ablehnung scheitert an der 361-Stimmen-Hürde – die Chatkontrolle 1.0 ist zurück.

Scharfe Kritik – bis in die eigenen Reihen

Der Widerstand kam quer durch die Fraktionen. Berichterstatterin Birgit Sippel (SPD) verurteilte das kurzfristig anberaumte Eilverfahren ohne Einbindung des Fachausschusses als „unlautere Manöver". Der Grünen-Abgeordnete Erik Marquardt sprach von einem schwarzen Tag für die Bürgerrechte und warf Metsola vor, ihre Rolle massiv überschritten zu haben. Selbst innerhalb der liberalen Renew-Fraktion regte sich Widerstand: Die Abgeordnete Irena Joveva betonte, das Haus könne die Massenüberwachung der Bevölkerung nicht einfach durchwinken. Und Patrick Breyer, der den Begriff „Chatkontrolle" einst prägte, bringt das eigentliche Muster auf den Punkt: Solange die von US-Konzernen umworbenen EU-Regierungen ihren bequemen Status quo der freiwilligen Massenscans immer wieder per Verfahrenstrick verlängert bekommen, haben sie keinen Anreiz, sich auf das zielgerichtete Kinderschutz-Konzept des Parlaments einzulassen.

Bemerkenswert am Rande: Das oft bemühte Argument, das Auslaufen der Regel im April habe eine gefährliche Rechtslücke gerissen, widerlegen neue Zahlen – das Bundeskriminalamt stellte nach dem Auslaufen keinen Einbruch der Verdachtsmeldungen fest.

Chatkontrolle 1.0 vs. Chatkontrolle 2.0 – bitte nicht verwechseln

Weil hier oft alles in einen Topf geworfen wird, lohnt die klare Trennung:

Chatkontrolle 1.0 ist eine seit 2020/2021 bestehende, befristete Ausnahme von der ePrivacy-Richtlinie. Sie erlaubt Anbietern, unverschlüsselte Kommunikation freiwillig auf bekanntes Missbrauchsmaterial zu scannen. Verschlüsselte Chats sind aussen vor. Genau diese Ausnahme wurde jetzt reaktiviert.

Chatkontrolle 2.0 ist die geplante, dauerhafte CSA-Verordnung (Child Sexual Abuse Regulation, CSAR), die die EU-Kommission im Mai 2022 vorgelegt hat. In ihrer ursprünglichen Fassung hätte sie Anbieter verpflichtet, sämtliche Kommunikation – auch verschlüsselte – per Client-Side-Scanning direkt auf dem Gerät zu durchleuchten, bevor Nachrichten überhaupt verschlüsselt werden. Diese Verordnung ist nicht beschlossen. Sie befindet sich weiter im Trilog zwischen Parlament, Rat und Kommission.

Der Grund, warum die Unterscheidung sicherheitstechnisch entscheidend ist: Client-Side-Scanning bricht das Sicherheitsmodell von Ende-zu-Ende-Verschlüsselung. Eine Hintertür für den Staat ist immer eine Hintertür für alle – ein Punkt, den die Kryptografie-Community seit Jahren einhellig betont. Signal-Präsidentin Meredith Whittaker hat mehrfach angekündigt, den europäischen Markt eher zu verlassen, als die Integrität der Verschlüsselung zu untergraben.

Die Vorgeschichte: ein „meistkritisiertes Gesetz aller Zeiten"

Die Chatkontrolle hat eine lange Geschichte des Scheiterns – und das ist der Kern dessen, was viele am aktuellen Vorgehen empört. Ein kompakter Zeitstrahl:

• 2020: Die EU führt eine befristete ePrivacy-Ausnahme ein, damit Anbieter freiwillig nach CSAM suchen dürfen. Ursprünglich als Sechs-Monats-Massnahme gedacht, danach wiederholt verlängert.
• Mai 2022: Die Kommission legt die CSAR vor. Der Begriff „Chatkontrolle", geprägt von Patrick Breyer, wird zum Sammelbegriff der Kritik.
• Juli 2022: Der Europäische Datenschutzausschuss (EDSA) und der Europäische Datenschutzbeauftragte (EDSB) kritisieren den Entwurf scharf.
• November 2023: Das Parlament legt seine Position fest – mit grundrechtsschonenderen Vorschlägen und dem klaren Ausschluss des Scannens verschlüsselter Inhalte.
• Juni 2024: Unter belgischer Ratspräsidentschaft wird eine Abstimmung im Rat in letzter Minute abgesagt, weil die Mehrheit fehlt.
• 2024: Der Wissenschaftliche Dienst des EU-Parlaments kommt zum Schluss, dass die CSAR gegen die Artikel 7 und 8 der EU-Grundrechtecharta verstösst.
• Oktober 2025: Der dänische Vorstoss für verpflichtendes Client-Side-Scanning findet im Rat keine ausreichende Unterstützung.
• November 2025: Der Rat einigt sich unter dänischer Präsidentschaft auf eine gemeinsame Position – und streicht die verpflichtenden Aufdeckungsanordnungen. Geblieben sind freiwilliges Scannen, Risikominderungspflichten, eine Altersverifikation und ein neues EU-Zentrum gegen Kindesmissbrauch.
• 26. März 2026: Das Parlament lehnt die Verlängerung der freiwilligen Ausnahme ab.
• 9. Juli 2026: Per Eilverfahren kehrt genau diese Ausnahme zurück.

Kurz: Seit 2022 ist der Entwurf trotz zahlreicher Anläufe von Ungarn, Schweden, Belgien und Dänemark nie regulär als verpflichtendes Gesetz verabschiedet worden. Dass eine bereits abgelehnte Regel nun über ein beschleunigtes Verfahren zurückkommt, reiht sich in dieses Muster ein.

Warum Datenschützer weiter Alarm schlagen

Auch wenn diesmal „nur" die freiwillige Variante betroffen ist und Verschlüsselung formal ausgenommen bleibt – die grundsätzlichen Einwände bleiben bestehen:

• Anlasslose Massenkontrolle: Ein flächendeckendes Scannen privater Nachrichten stellt Millionen Unverdächtige unter Generalverdacht. Kritiker halten dem das Konzept des Parlaments entgegen: Kinder würden durch zielgerichtete, anlassbezogene Strafverfolgung wirksamer geschützt als durch das Durchleuchten der Kommunikation Unschuldiger.
• Fragwürdige Trefferquote: Breyer verweist auf Zahlen der deutschen Bundespolizei, wonach ein grosser Teil der Meldungen von vornherein nicht strafrechtlich relevant ist.
• Die Architektur ist eine Blaupause: Auch ohne Scan-Zwang gilt – einmal gebaut, lässt sich eine Überwachungsinfrastruktur politisch ausweiten. Der EDSA warnt genau davor: Ein „freiwilliges" Scannen in Kombination mit weit gefassten Risikominderungspflichten ist funktional kaum von verpflichtendem Scannen zu unterscheiden.
• Der neue Schauplatz Altersverifikation: Während der Scan-Zwang vorerst vom Tisch ist, rückt eine verpflichtende Altersverifikation in den Vordergrund – die in der Praxis schnell zu einer faktischen Ausweispflicht für weite Teile des Internets führen kann und anonyme Kommunikation gefährdet.

Was ihr jetzt konkret tun könnt

Panik hilft nicht, Vorsorge schon. Solange kein Scan-Zwang gilt, bleibt eure Kommunikation über Ende-zu-Ende-verschlüsselte Dienste privat – und ihr macht euch unabhängiger von einzelnen Plattformen und deren freiwilligen Scans:

• Setzt auf konsequent verschlüsselte Messenger wie Signal oder Element statt auf Dienste, deren Datenschutz von einer politischen Ausnahmeregel abhängt.
• Nutzt selbstgehostete Infrastruktur, wo es geht – von der eigenen Cloud bis zur eigenen Mail. Wer die Kontrolle über die eigenen Daten behalten will, gibt sie nicht freiwillig an Grosskonzerne ab, die morgen zum Scannen verpflichtet oder ermächtigt werden könnten.
• Bleibt informiert und laut: Der Streit um die dauerhafte Chatkontrolle 2.0 hat, wie Breyer sagt, „erst begonnen". Die Trilog-Verhandlungen laufen weiter.

Fazit

Die Schlagzeile „EU beschliesst Chatkontrolle im Eilverfahren" ist zugespitzt, aber im Kern nicht falsch: Das Parlament hat eine erst im März abgelehnte Überwachungsregel über einen Verfahrenstrick zurückgeholt, der die Beweislast umkehrt und die Sommerpause ausnutzt. Dass es dabei „nur" um die freiwillige Chatkontrolle 1.0 für unverschlüsselte Inhalte geht und Verschlüsselung ausgenommen bleibt, ist ein wichtiger Unterschied – aber kein Grund zur Entwarnung. Denn das eigentliche Signal ist ein anderes: Wenn ein demokratisch gefälltes „Nein" per Eilverfahren in ein „Ja" verwandelt werden kann, dann ist digitale Souveränität keine Frage des Vertrauens in Institutionen, sondern eine Frage der eigenen Infrastruktur. Verschlüsselung, Selbsthosting und Unabhängigkeit von Plattformen sind keine Nische mehr – sie sind die Versicherung gegen genau solche Kehrtwenden.

Dieser Beitrag fasst den Stand vom 10. Juli 2026 zusammen. Das Gesetzgebungsverfahren läuft weiter; Kommission und Rat müssen der Parlamentsposition noch abschliessend zustimmen.

The post EU beschliesst Chatkontrolle Light im Eilverfahren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Beitrag zerlegen wir, was BIP-110 überhaupt ist, warum die Aktivierungsmethode ein Denkfehler ist, weshalb die entstehende «Supporter-Chain» nicht lebensfähig sein kann und warum die Behauptung, man müsse sich «aus Sicherheitsgründen» anschliessen, das Gegenteil der Wahrheit ist.

Was ist BIP-110 überhaupt?

BIP-110 trägt den offiziellen Titel Reduced Data Temporary Softfork und wurde von einem Autor unter dem Pseudonym Dathon Ohm eingereicht (ursprünglich als BIP-444 im Oktober 2025). Es handelt sich um einen auf ein Jahr befristeten Soft Fork, der die Menge an beliebigen Daten begrenzen soll, die man in Bitcoin-Transaktionen unterbringen kann. Ziel sind Ordinals, Inscriptions, grosse OP_RETURN-Payloads und ähnliche Konstruktionen. Die Details stehen auf der Kampagnenseite bip110.org.

Konkret führt BIP-110 sieben neue Gültigkeitsregeln ein, unter anderem:

• Neue Outputs werden auf 34 Bytes begrenzt, OP_RETURN auf maximal 83 Bytes.
• Daten-Pushes und Witness-Elemente werden auf 256 Bytes gedeckelt.
• Bestimmte Opcodes, Taproot-Annexes und grosse Control Blocks werden temporär eingeschränkt.
• UTXOs, die vor der Aktivierung existierten, sind dauerhaft ausgenommen – bestehende Gelder sind also nicht direkt betroffen.

Die Regeln laufen nach rund 52'416 Blöcken (etwa ein Jahr) automatisch wieder aus. Wichtig für die Einordnung: BIP-110 wird nicht in Bitcoin Core entwickelt, sondern baut auf Bitcoin Knots auf – jener alternativen Node-Software, die Luke Dashjr pflegt und die bereits konservativere Filter mitbringt. Wer den grundsätzlichen Unterschied zwischen den beiden Implementierungen verstehen will, findet das in unserem älteren Beitrag Bitcoin Knots vs. Bitcoin Core.

Der Aktivierungsmechanismus: 55 % statt 95 % – und dann Zwang

Hier wird es interessant, und hier liegt der eigentliche Sprengstoff. BIP-110 nutzt einen modifizierten BIP9-Mechanismus: Miner signalisieren Zustimmung, indem sie Bit 4 im Versionsfeld ihrer Blöcke setzen. Für ein frühes Lock-in genügen laut Spezifikation 55 % der Blöcke innerhalb einer Difficulty-Periode (1'109 von 2'016) – nicht die historisch üblichen 95 %.

Der eigentliche Hebel ist aber das Forced Signaling (Mandatory Signaling). Ab Block 961'632 – projiziert auf ca. den 7. August 2026, gegen 17:59 UTC – lehnen BIP-110-Nodes jeden Block ab, der Bit 4 nicht setzt. Das Fenster läuft bis Block 963'647. Die Idee: Miner sollen gezwungen werden, mitzumachen, weil ihre Blöcke sonst von den BIP-110-Nodes als ungültig verworfen werden.

Genau das hat Dathon Ohm Ende Juni öffentlich als «ATTENTION. THIS IS NOT A DRILL» angekündigt: Alle Miner müssten Bit 4 setzen, sonst würden ihre Blöcke als ungültig verworfen. Das klingt nach einer Drohung mit Autorität – ist in Wahrheit aber ein Bluff, und das lässt sich vorrechnen.

Der zentrale Denkfehler: Forced Signaling ohne Hashrate

Befürworter ziehen gern die Segwit-Aktivierung von 2017 als Vorbild heran. Der Vergleich hinkt an der entscheidenden Stelle. Bei Segwit stand am Ende eine grosse Mehrheit der Hashpower hinter der Aktivierung – die Segwit-Chain war die längste Chain, und selbst Nicht-Unterstützer folgten ihr nach geltender «heaviest chain»-Regel automatisch. Der oft zitierte UASF (BIP148) musste 2017 gar nie scharf geschaltet werden, weil Segwit letztlich über Miner-Signaling (MASF) aktiviert wurde. Das erklärt auch Jameson Lopp ausführlich in seinem Layman's Guide to BIP-110.

Bei BIP-110 ist die Ausgangslage umgekehrt. Das Signaling lag Ende Juni 2026 bei rund 0,31 % der Hashrate – etwa 5 EH/s von rund 940 EH/s im Netzwerk, zeitweise sogar 0,00 %. Kein einziger grosser Pool signalisiert; die Signalblöcke stammen praktisch ausschliesslich von Ocean, dem Pool von Luke Dashjr. Bei so wenig Rückhalt passiert Folgendes:

1. Ab dem Forced Signaling verwerfen die BIP-110-Nodes alle Blöcke ohne Signal.
2. Die Blöcke ohne Signal stellen aber die überwältigende Mehrheit – die Nicht-Supporter-Chain ist damit die längere Chain.
3. Nicht-Unterstützer minen auf der Nicht-Supporter-Chain weiter, die wenigen Unterstützer auf ihrer eigenen. Ergebnis: ein Chain-Split.

Und jetzt kommt der Teil, den die Befürworter nicht gern rechnen. Es gibt keine Anpassung der Difficulty beim Split. Auf der BIP-110-Chain arbeiten aber nur noch ein Bruchteil der Miner. Bei 1 % der Hashrate dauert ein Block im Schnitt nicht mehr 10 Minuten, sondern rund 17 Stunden. Bei den real signalisierten ~0,31 % wären es über 53 Stunden – mehr als zwei Tage pro Block.

Noch dramatischer ist das Difficulty-Retargeting: Die Schwierigkeit passt sich erst nach 2'016 Blöcken an. Bei 1 % Hashrate würde diese erste Anpassung erst nach rund 3,8 Jahren greifen. Eine Chain, auf der man tagelang auf eine einzige Bestätigung wartet und die sich fast vier Jahre lang nicht selbst korrigieren kann, ist schlicht nicht als Geldnetzwerk brauchbar. Die zentrale Frage aus der Community bleibt unbeantwortet: Wie soll diese Chain lebensfähig sein?

Adam Back bringt es auf den Punkt: Was hier entstünde, wäre kein Bitcoin-Upgrade, sondern eher eine separate Coin – vergleichbar mit Bitcoin Gold, das 2017 zwar abspaltete, aber nie das Original herausforderte.

Warum ein Chain-Split gefährlich ist – auch für euch

Ein Chain-Split ohne Replay-Schutz ist kein theoretisches Ärgernis. Das letzte Mal, dass Bitcoin einen Split ohne Replay-Schutz erlebte, war 2013. Lopp, der 2017 bei BitGo die Infrastruktur auf den beinahe eingetretenen SegWit2X-Split vorbereiten musste, beschreibt genau dieses Szenario als Albtraum: Unsicherheit darüber, welche Chain «gewinnt», Double-Spend-Risiko und ein Ökosystem, das vorsorglich zum Stillstand kommt.

Besonders heikel wird es für Layer 2, allen voran das Lightning Network. Lightning-Sicherheit beruht auf einer stillschweigenden Annahme: Beide Channel-Partner sehen dieselbe Chain und können darauf im Streitfall dieselben Transaktionen durchsetzen. Bei einem Split mit zwei unterschiedlichen Chain-Tips fällt diese Annahme weg. Die Folge sind mehrere neue Angriffsflächen:

• Justice- bzw. Penalty-Transaktionen können ins Leere laufen. Wenn ein Betrugsversuch nur auf einer der beiden Chains sichtbar ist, kann die Straftransaktion auf der anderen Chain wirkungslos bleiben – oder wegreorganisiert werden.
• Timelocks verhalten sich unerwartet, weil die beiden Chains unterschiedlich schnell wachsen und Blockhöhen auseinanderdriften.
• Watchtowers reagieren zu spät oder auf der falschen Chain, weil sie den relevanten Broadcast nicht dort sehen, wo er zählt.
• Bestätigungen vermitteln eine Scheinsicherheit, obwohl dieselben Coins auf der Gegen-Chain noch verschiebbar sind.

Wir nennen hier bewusst keine Schritt-für-Schritt-Anleitung – die Mechanik ist konkret genug ausgearbeitet worden, dass sie in der Community bereits als Diebstahlsszenario diskutiert wird. Genau das ist der Punkt: Ein erzwungener Split verwandelt eine ideologische Debatte in ein handfestes finanzielles Risiko für unbeteiligte Dritte. Auch BitMEX Research warnte, dass ein Angreifer im Extremfall sogar illegale Inhalte on-chain platzieren könnte, um eine gewünschte Reorg zu erzwingen – ausgerechnet eine Folge der Zensur-Logik, die BIP-110 verkauft.

Dazu kommt ein handwerkliches Problem: Ein Bitcoin-Core-Entwickler (l0rinc) fand im BIP-110-Code einen Konsensfehler rund um Cache-Poisoning bei einer Reorg an der Aktivierungsgrenze, der monatelang unbemerkt blieb. Für einen Vorschlag, der das Fundament des Netzwerks anfassen will, ist das kein gutes Zeichen.

Warum BIP-110 nichts bringt: Bitcoin regelt Spam über Gebühren

Der ganze Aufwand wäre vielleicht noch diskutabel, wenn er sein Ziel erreichte. Tut er nicht. Bitcoin reguliert «Spam» seit jeher selbst – über einen offenen Markt für Blockspace und die Gebühren. Wer Daten unterbringen will, zahlt dafür; teurer Blockspace verdrängt minderwertige Nutzung von allein. Das ist der marktwirtschaftliche, zensurfreie Mechanismus, und er funktioniert ohne dass jemand entscheiden muss, welche Transaktion «erwünscht» ist.

BIP-110 ersetzt diesen Mechanismus durch eine subjektive Regel darüber, was in einen Block darf – also durch Zensur. Und selbst diese Zensur ist trivial umgehbar: Peter Todd hat den kompletten BIP-110-Text on-chain eingebettet und dabei alle Regeln des Vorschlags eingehalten, um zu demonstrieren, dass sich die Beschränkungen mit minimalem Aufwand aushebeln lassen. Ein Filter, der das Grundprinzip der Zensurresistenz opfert und trotzdem nicht filtert, ist das schlechteste beider Welten.

Die Reaktionen aus der Branche fallen entsprechend deutlich aus. Alex Thorn von Galaxy Digital nannte den Soft Fork einen «Angriff auf Bitcoin», Michael Saylor stufte ihn als Protokoll-Bedrohung ein, und Lopp bezeichnet den Vorschlag schlicht als rücksichtslos und zum Scheitern verurteilt.

«Gefährlich, sich nicht anzuschliessen»? Genau umgekehrt

Aus dem Umfeld von Luke Dashjr kommt das Narrativ, es sei gefährlich, sich BIP-110 nicht anzuschliessen – Miner riskierten, dass ihre Blöcke verworfen würden. Diese Drohung dreht die Realität um.

Verworfen werden die Blöcke nur von den BIP-110-Nodes selbst. Ein Soft Fork, der Blöcke ablehnt, funktioniert nur dann, wenn die ablehnenden Nodes jene sind, die ein Miner zwingend braucht, um seine Coinbase-Rewards zu «verkaufen» – also die wirtschaftlich relevanten Nodes, an denen Börsen, Zahlungsdienstleister und Nutzer hängen. Bei einem Rückhalt von unter 1 % ist das nicht der Fall. Die BIP-110-Nodes haben, wie Lopp trocken feststellt, keine ökonomische Macht. Wer nicht signalisiert, bleibt schlicht auf der Chain mit der gesamten Hashpower, der gesamten Liquidität und dem gesamten Ökosystem.

Die neueste Volte: «Null Blöcke lehnen BIP-110 ab»

Weil das «gefährlich, nicht mitzumachen»-Narrativ nicht verfängt, wird das Argument inzwischen schlicht auf den Kopf gestellt. Auf den Einwand, dass unter 1 % der Miner BIP-110 unterstützen, entgegnet Dashjr, «readiness» sei nicht dasselbe wie Unterstützung, Miner träfen die Entscheidung ohnehin nicht – und bemerkenswerterweise gebe es «zero blocks signalling rejection of BIP110». Kein einziger Block signalisiere also eine Ablehnung, ergo laufe es auf eine erfolgreiche Aktivierung hinaus.

Das ist ein rhetorischer Taschenspielertrick. Im Signaling-Mechanismus von Bitcoin gibt es kein «Nein»-Bit. Die einzige Möglichkeit, einen Soft Fork abzulehnen, besteht darin, Bit 4 nicht zu setzen – und genau das tun über 99 % der Blöcke. Schweigen ist hier keine Zustimmung, sondern die einzige verfügbare Form des Widerspruchs, und sie fällt so deutlich aus, wie sie nur ausfallen kann. Die Behauptung, das Fehlen expliziter Ablehnungsblöcke bedeute Zustimmung, ist ungefähr so schlüssig wie die Aussage, alle seien dafür, weil auf dem Stimmzettel keine «Dagegen»-Box abgedruckt war.

Auch die beiden Vorstufen des Arguments tragen nicht. «Readiness» ohne Signal ist für die Aktivierung schlicht unsichtbar – der Mechanismus zählt gesetzte Bits, keine unausgesprochenen Absichten. Und der Satz «Miner entscheiden nicht» ist die klassische UASF-Denkfigur: Angeblich entscheiden die wirtschaftlich relevanten Nodes. Das funktioniert aber nur, wenn diese Nodes ökonomisches Gewicht haben – bei einem Rückhalt im Promillebereich haben sie das nachweislich nicht.

Zudem stimmt schon die Prämisse nicht: Grosse Pools wie F2Pool haben BIP-110 öffentlich abgelehnt. Und selbst wenn ein kleiner Teil der Hashrate mitzöge, wäre eine Minderheits-Chain für Miner wirtschaftlich unattraktiv: Coinbase-Rewards sind erst nach 100 Bestätigungen ausgabefähig – bei zwei Blöcken pro Tag rund 50 Tage, und Börsen würden auf einer Chain mit Minderheits-Hashrate wegen des Reorg-Risikos noch weit mehr Bestätigungen verlangen. Rationale Miner bleiben auf so einer Chain schlicht nicht.

Gefährlich ist also nicht das Nicht-Mitmachen. Gefährlich ist der Versuch, eine Regeländerung ohne Konsens zu erzwingen und dabei einen Split zu provozieren, der reale Gelder auf Layer 2 gefährdet. Die hohen Node-Zahlen von Knots taugen dabei nicht als Gegenargument: Nodes sind nicht Sybil-resistent, das Betreiben ist billig, und der auffällig hohe Tor-Anteil unter den signalisierenden Nodes lässt vermuten, dass hinter vielen «Stimmen» wenige Akteure stehen.

Fazit

BIP-110 ist ein Lehrstück darüber, wie man es nicht macht. Der Vorschlag will ein Problem lösen, das der Gebührenmarkt bereits regelt, mit einem Mittel – Zensur –, das dem Kern von Bitcoin widerspricht, über einen Mechanismus, der ohne Hashrate-Mehrheit nur einen unbrauchbaren Chain-Split erzeugen kann, und mit Regeln, die sich nachweislich umgehen lassen. Übrig bleibt ein reales Risiko für Lightning-Nutzer und ein Reputationsschaden für ein Netzwerk, dessen wichtigste Eigenschaft gerade seine Berechenbarkeit und Zensurresistenz ist.

Unsere Empfehlung ist unaufgeregt: Lasst euch von «THIS IS NOT A DRILL»-Rhetorik nicht drängen. Betreibt die Node-Software, der ihr vertraut, versteht die Aktivierungsmechanik, und behaltet – gerade wenn ihr Lightning-Channels betreibt – die erste Augustwoche im Auge. Mit an Sicherheit grenzender Wahrscheinlichkeit verpufft BIP-110 als lautes, aber folgenloses Ereignis. Vorbereitet zu sein, kostet nichts. Panik dagegen ist genau das, was hier verkauft werden soll.

The post BIP-110: Warum es nichts bringt und wieso es sogar gefährlich ist appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Höchste Zeit für ein Update. Wir schauen uns an, was konkret behauptet wird, wie das zu den Lücken passt, die wir damals schon beschrieben haben – und vor allem: was davon belegt ist und was reine Behauptung bleibt.

Worum geht es? Gleich mehrere Verfahren auf einmal

Wer die Schlagzeilen verfolgt, verliert schnell den Überblick, weil mehrere Sachen parallel laufen. Eine Übersicht des Strafverteidigers Jens Ferner bringt etwas Ordnung hinein – es sind im Kern diese Stränge:

Die internationale Sammelklage in San Francisco. Eingereicht Ende Januar 2026 von der Kanzlei Quinn Emanuel vor einem Bundesgericht im Nordbezirk Kalifornien. Geklagt hat eine Gruppe von Nutzern aus Australien, Brasilien, Indien, Mexiko und Südafrika, stellvertretend für die über drei Milliarden WhatsApp-Nutzer. Die Klage spricht von einer „kleptographischen Backdoor" und wirft Meta irreführende Geschäftspraktiken vor.

Eine Whistleblower-Klage seit September 2025. Hier geht es um einen ehemaligen WhatsApp-Mitarbeiter.

Eine Untersuchung des US-Handelsministeriums. Sie prüfte Aussagen ehemaliger Content-Moderatoren, die über den Dienstleister Accenture für Meta gearbeitet haben sollen. Pikant: Diese Untersuchung wurde im April 2026 laut Bloomberg abrupt eingestellt – ein Ermittler hatte zuvor über zehn Monate Material gesammelt und intern festgehalten, Meta speichere verschlüsselte WhatsApp-Nachrichten und könne sie lesen.

Die Klage des Bundesstaats Texas. Im Mai 2026 reichte das Büro von Generalstaatsanwalt Ken Paxton eine eigene Klage unter dem Texas Deceptive Trade Practices Act ein und fordert Zivilstrafen pro Verstoss.

Es ist also kein einzelner Querulant, sondern eine ganze Welle. Das macht die Sache interessant – sagt aber für sich genommen noch nichts über den Wahrheitsgehalt aus.

Der Kern des Vorwurfs: das „Task"-System

Im Zentrum aller Vorwürfe steht ein angeblicher interner Mechanismus. Laut Klageschrift müsse ein Meta-Mitarbeiter lediglich einen „Task", also eine Anfrage über ein internes System, an ein Engineering-Team senden, um Zugriff auf Chats zu erhalten. Dieser Zugriff werde dann oft „ohne jegliche Prüfung" gewährt.

Besonders brisant: Laut Darstellung der Kläger liessen sich die Nachrichten danach nahezu in Echtzeit und auch rückwirkend einsehen – ohne zusätzlichen Entschlüsselungsschritt. Genau das ist der Punkt, der über alles hinausgeht, was wir im Ursprungsartikel beschrieben haben. Es wäre eben nicht „nur" das bekannte Backup-Loch oder die Meldefunktion, sondern ein direkter Live-Zugriff auf laufende, eigentlich Ende-zu-Ende-verschlüsselte Kommunikation.

Wie passt das zu den Lücken, die wir längst beschrieben haben

Wer unseren ersten Artikel gelesen hat, kennt die realen Schwachstellen schon. Und genau hier wird es spannend, weil die Klage teils auf bekanntem, belegtem Terrain aufbaut – und teils weit darüber hinausschiesst.

Belegt und unbestritten:

• Unverschlüsselte Backups. Wer die E2EE-Backups nicht aktiv einschaltet, hat seinen Chatverlauf in Google Drive oder iCloud in einer Form liegen, auf die der Anbieter zugreifen kann. WhatsApp schreibt selbst in den Support-Dokumenten, dass Backups in der Cloud nicht durch die WhatsApp-E2EE geschützt sind. Verschlüsselte Backups gibt es zwar seit Ende 2021 – aber standardmässig sind sie nicht aktiv.
• Die Meldefunktion (Message Franking). Wird eine Nachricht gemeldet, werden die letzten fünf Nachrichten im Klartext an WhatsApp übertragen. Das ist ein bekannter, dokumentierter Mechanismus – und genau hier liegt der wahre Kern hinter der Accenture-Geschichte: Moderatoren sichten gemeldete Inhalte.
• Metadaten. Wer mit wem, wann, wie oft, von welcher IP – das alles wird erhoben und fällt nicht unter „Inhalt".

Behauptet, aber unbewiesen:

• Der angebliche Live-Zugriff per „Task" auf beliebige laufende Chats. Hier ist die zentrale Frage, ob die Aussagen der ehemaligen Moderatoren auf einem Missverständnis über den legitimen Melde-Mechanismus beruhen oder tatsächlich einen darüber hinausgehenden systematischen Zugang beschreiben. Das ist bislang ungeklärt.

Was ist belegt – und was nicht

An dieser Stelle lohnt sich Ehrlichkeit statt Empörung. Die Sammelklage stützt sich auf anonyme Whistleblower und liefert keinen technischen Beweis – keinen Code, keine Netzwerk-Mitschnitte, kein Audit, das eine kryptografische Hintertür belegt. Die Behauptungen sind zum jetzigen Zeitpunkt also unbewiesen.

Meta weist die Vorwürfe entsprechend scharf zurück und nennt die Klage „kategorisch falsch" und ein „absurdes Werk der Fiktion"; man setze seit einem Jahrzehnt auf das Signal-Protokoll.

Auch unabhängige Stimmen sind skeptisch. Kryptografie-Fachleute geben zu bedenken, dass eine Hintertür, die Milliarden Nachrichten entschlüsselt, extrem komplex und kaum zu verbergen wäre – Sicherheitsforschende analysieren regelmässig die Binärdateien der App. Eine flächendeckende Backdoor müsste irgendwann auffallen.

Das heisst aber nicht, dass „alles gut" ist. Die Trennung ist entscheidend:

• Die starke These (ein Knopf für Live-Zugriff auf jeden Chat) ist denkbar, aber nicht erhärtet.
• Das abgeschwächte Bild (Meta und Google kommen bei sehr vielen Nutzern faktisch an Inhalte – über unverschlüsselte Backups, über die Moderationspipeline, über Metadaten) ist dagegen belegt und kein Verschwörungsszenario.

Genau diese Vermengung ist es, die solche Klagen plausibel wirken lässt: Wer sagt „Meta kann meine Nachrichten lesen", liegt für die meisten Standard-Setups praktisch richtig – auch ohne dass die Live-E2EE selbst geknackt sein muss.

Der wunde Punkt bleibt: Closed Source

Warum lässt sich der Vorwurf nicht einfach widerlegen? Weil WhatsApp proprietäre Software ist. Ihr könnt den Quellcode nicht einsehen und nicht überprüfen, ob das ausgelieferte Programm wirklich das tut, was das Whitepaper behauptet. Das Signal-Protokoll selbst ist solide und öffentlich dokumentiert – aber das Vertrauen endet bei der konkreten Implementierung von Meta.

Genau das ist der Unterschied zu echten Privacy-Messengern: Bei Signal beziehungsweise dem Fork Molly ist der Code offen und nachvollziehbar, bei Matrix ebenso. Vertrauen muss man sich verdienen – und Nachprüfbarkeit ist die einzige seriöse Grundlage dafür.

Fazit: Ob die Klage gewinnt oder nicht – euer Risiko bleibt gleich

Spannend an den Verfahren ist weniger das Urteil, das ohnehin Jahre dauern kann, sondern was sie ans Licht bringen. Aber für die Praxis ändert das Ergebnis erstaunlich wenig: Solange ihr WhatsApp mit Standard-Einstellungen nutzt, sind eure Inhalte über unverschlüsselte Backups und die Meldefunktion ohnehin angreifbar – ganz unabhängig davon, ob es das „Task"-System in der behaupteten Form gibt.

Unsere Empfehlung ist deshalb dieselbe geblieben:

• Aktiviert mindestens die verschlüsselten Backups (und denkt daran: das bringt nur etwas, wenn auch euer Gegenüber es tut – sonst liegt euer Chat in dessen unverschlüsseltem Backup).
• Schränkt die Berechtigungen ein und nutzt auf GrapheneOS die Storage Scopes.
• Und wenn euch Privatsphäre wirklich wichtig ist: wechselt zu einem offenen, nachprüfbaren Messenger wie Signal/Molly oder Matrix.

Die ganzen praktischen Tipps haben wir im ursprünglichen Artikel zusammengefasst. Die Klagen sind ein gutes Druckmittel und ein wichtiges Signal – aber das eigentliche Problem ist und bleibt: Eine App, die ihr nicht überprüfen könnt, müsst ihr glauben. Und Glauben ist im Datenschutz die schwächste aller Garantien.

The post WhatsApp-Verschlüsselung vor Gericht: Aus „theoretischer Hintertür" wird ein Gerichtsfall appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In Wirklichkeit verwechselt dieses Argument zwei grundverschiedene Dinge: wer ein Gerät herstellt und wer die Software darauf kontrolliert. Wir wollen diesen Mythos in diesem Artikel technisch sauber auseinandernehmen, ehrlich bei den Grenzen bleiben (denn nichts ist zu 100 Prozent sicher) und am Ende klar einordnen, was tatsächlich möglich ist – und was nicht. Vorweg: Großflächige, automatisierte Überwachung über euer GrapheneOS-Pixel ist nicht möglich. Was bleibt, sind teure, gezielte Angriffe gegen Einzelpersonen. Der Unterschied ist entscheidend.

Der Denkfehler: Hardware-Hersteller ist nicht gleich Software-Kontrolle

Google fertigt die Pixel-Geräte nicht einmal selbst – das tun Auftragsfertiger. Vor allem aber: Wer ein Stück Hardware produziert, hat damit noch lange keinen dauerhaften Zugang zu dem, was später darauf läuft. Genau hier setzt GrapheneOS an. Es ersetzt das komplette Betriebssystem. Was nach dem Flashen auf dem Gerät läuft, ist nicht mehr Googles Android, sondern ein quelloffenes, gehärtetes System, das ihr selbst kontrolliert.

Der entscheidende Mechanismus dahinter heißt Verified Boot – und er funktioniert auf den Pixels ausgerechnet besonders gut.

Verified Boot mit euren eigenen Schlüsseln

Bei einem handelsüblichen Smartphone ist der Bootloader auf die Schlüssel des Herstellers verriegelt. Beim Pixel lässt sich der Bootloader jedoch entsperren, GrapheneOS flashen – und danach wieder verriegeln. Und das ist der springende Punkt: Beim erneuten Verriegeln übernimmt das Gerät die kryptografischen Schlüssel von GrapheneOS, nicht die von Google.

Verified Boot prüft beim Start jede Stufe der Boot-Kette kryptografisch, bevor sie ausgeführt wird. Der dedizierte Sicherheitschip im Pixel – der Titan M2 – erzwingt dabei, dass nur Software startet, die mit genau dem Schlüssel signiert ist, auf den ihr das Gerät verriegelt habt. Lädt jemand manipulierten Code oder versucht, ein anderes System unterzuschieben, schlägt die Prüfung fehl und das Gerät warnt euch oder bootet gar nicht erst. Der Witz daran: Googles Signaturschlüssel sind in dieser Vertrauenskette für das Betriebssystem schlicht nicht mehr enthalten. Das Pixel vertraut nach dem Relock GrapheneOS – nicht Google.

Die Hardware, die Google liefert, arbeitet damit für euch: Der von Google verbaute Sicherheitschip schützt ein System, das Google nicht mehr kontrolliert. Das ist keine Ironie, sondern saubere Sicherheitsarchitektur.

Kein Google im System

Der zweite Baustein ist ebenso wichtig. Standardmäßig laufen auf GrapheneOS keine Google Play Services. Es gibt keine eingebaute Telemetrie, keine Werbe-ID, keine automatischen Cloud-Backups zu Google, keine im Hintergrund mitlaufenden Google-Dienste mit Systemrechten.

Wer Play Services braucht, kann sie als sogenannte sandboxed Play Services nachinstallieren. Und auch hier ist die Architektur entscheidend: Diese laufen dann als ganz normale, unprivilegierte App in einer Sandbox – ohne Sonderrechte, ohne Zugriff auf andere Apps, ohne Systemberechtigungen, die ihnen GrapheneOS nicht ausdrücklich erteilt. Sie sehen genau so viel wie jede andere App, der ihr nichts erlaubt habt: nämlich praktisch nichts. Damit fällt der gesamte Mechanismus weg, über den Mainstream-Android Daten im großen Stil sammelt.

Genau das ist der entscheidende Hebel gegen Massenüberwachung: Sie funktioniert über systematische Datensammlung – Telemetrie, Cloud-Sync, Geräte-IDs, vorinstallierte Dienste mit Tiefenzugriff. GrapheneOS entfernt diese Vektoren. Damit ist die Voraussetzung für flächendeckendes, automatisiertes Mitlesen schlicht nicht mehr gegeben.

Das Modem-Argument: was der Baseband wirklich kann

Jetzt zum technisch anspruchsvollsten Teil, an dem sich die meisten Ängste festmachen: dem Modem, auch Baseband genannt. Der Vorwurf lautet, das Mobilfunk-Modem laufe mit geschlossener Firmware und habe „Zugriff auf alles, was durchgeht". Daraus wird dann gefolgert, Google, Provider oder Behörden könnten über das Modem das gesamte Gerät einsehen.

Hier müssen wir präzise sein, denn an dem Argument ist ein wahrer Kern – aber die Schlussfolgerung ist falsch.

Wahr ist: Die Modem-Firmware ist proprietär. Niemand außerhalb des Herstellers kann sie vollständig auditieren. Das ist eine reale, verbleibende Vertrauensannahme, und seriöse Sicherheitsforschung verschweigt das auch nicht.

Falsch ist die Annahme, dieses Modem könne deshalb beliebig auf den Hauptspeicher und eure Daten zugreifen. Auf den offiziell unterstützten Geräten ist der Baseband isoliert. Eine sogenannte IOMMU (Input-Output Memory Management Unit) sitzt zwischen Modem und Arbeitsspeicher und beschränkt den Speicherzugriff des Modems auf einen winzigen, klar abgegrenzten Bereich – nämlich auf internen Modemspeicher und exakt den Speicher, den die Treiber bewusst mit ihm teilen. Historisch hatte der Baseband per Direct Memory Access tatsächlich vollen Zugriff auf das RAM des Hauptprozessors; ein kompromittiertes Modem konnte damit das ganze System unterlaufen. Genau diese Schwachstelle schließt die IOMMU-Isolation.

Wichtig ist dabei ein oft missverstandener Punkt: Ob eine Komponente auf einem separaten Chip sitzt, sagt nichts über ihre Isolation aus. Entscheidend ist, dass die Treiber sie als nicht vertrauenswürdig behandeln und ihren Zugriff hart begrenzen. Genau das leisten die Pixel-Plattform und GrapheneOS. Auf den aktuellen Qualcomm-basierten Geräten sind außerdem WLAN und Bluetooth als isolierte, sandboxed Prozesse umgesetzt, statt auf einem schlecht eingehegten Zusatzchip zu laufen.

Was das Modem also sehen kann, ist der Netzwerkverkehr, der über den Mobilfunk läuft. Was es nicht kann, ist euren Speicher auslesen, eure Dateien exfiltrieren oder beliebig das Hauptsystem übernehmen – solange die Isolation hält.

Damit ist aber erst die eine Hälfte des Modem-Arguments beantwortet, nämlich der gefürchtete Datenzugriff. Die zweite Hälfte ist die Sorge vor einem „Killswitch": Könnte jemand über das Modem nicht eure Daten lesen, sondern euer Gerät einfach fernabschalten – und das massenhaft? Diese Frage gehört sauber getrennt, weil sie ein ganz anderes Bedrohungsmodell beschreibt.

Der Killswitch-Mythos: Netz abschalten ist nicht gleich Handy fernsteuern

Hinter der Killswitch-Angst stecken in Wahrheit drei völlig verschiedene Dinge, die ständig zu einem einzigen Schreckgespenst vermischt werden. Sortieren wir sie.

Erstens: die Netzsperre. Ja, ein Mobilfunknetz kann euch den Dienst verweigern – einzelne Geräte über eine IMEI-Sperre, ganze Regionen über eine Abschaltung der Funkzellen. Solche flächendeckenden Netz-Blackouts hat es real gegeben, und sie sind tatsächlich „massenhaft" möglich. Aber: Das ist eine Dienstverweigerung, kein Fernzugriff. Das Netz hört auf, euch zu bedienen – niemand übernimmt dabei euer Gerät, liest eure Daten oder „brickt" die Hardware. Euer Telefon funktioniert weiter, nur eben ohne Mobilfunk: WLAN, lokale Apps, gespeicherte Daten bleiben nutzbar. Und das Wichtigste: Davon ist jedes Telefon gleichermaßen betroffen, völlig unabhängig vom Betriebssystem. GrapheneOS kann eine Netzabschaltung nicht verhindern – aber es wird dabei auch nicht gesondert herausgegriffen. Wer gegen genau dieses Szenario gewappnet sein will, setzt auf netzunabhängige Kanäle: WLAN, Mesh, Offline-Funktionen.

Zweitens: der Diebstahlschutz-Killswitch. Seit einigen Jahren ist in mehreren Rechtsräumen ein Anti-Diebstahl-Killswitch vorgeschrieben – also die Möglichkeit, ein verlorenes Gerät aus der Ferne zu sperren oder zu löschen. Wichtig zu verstehen: Dieser Mechanismus sitzt nicht im Modem, sondern auf Betriebssystem- und Cloud-Ebene und hängt an eurem Konto, bei Stock-Android also an Googles „Find My Device". Auf GrapheneOS ohne Google-Dienste existiert dieser Google-Haken schlicht nicht. Ironischerweise entfernt GrapheneOS damit genau den Fernabschalt-Vektor, den viele fürchten.

Drittens: die geheime Modem-Backdoor zum Fernbricken. Das ist der eigentliche Kern des Mythos – und der Teil, der dem Vertrauensmodell der Hardware widerspricht. Die Firmware des Modems wird ausschließlich mit Schlüsseln signiert und validiert, die allein der Chip-Hersteller Qualcomm besitzt. Nur Qualcomm kann diese Firmware überhaupt aktualisieren. Ein beliebiger Provider, ein Geheimdienst oder ein Angreifer kann dem Modem also nicht einfach eine manipulierte „Abschalt-Firmware" unterschieben. Auf GrapheneOS kommt erschwerend hinzu: Die Radio- und Modem-Firmware ist Teil des signierten GrapheneOS-Update-Pakets, das euer Gerät kryptografisch prüft, bevor es es akzeptiert. Es gibt keinen Kanal, über den der Mobilfunkanbieter dem Modem im laufenden Betrieb beliebige Firmware nach Belieben aufzwingt. Und selbst wenn ein Modem kompromittiert würde, hält die IOMMU-Isolation es davon ab, das Hauptsystem zu bricken oder eure Daten zu greifen – es könnte im schlimmsten Fall den Mobilfunk stören, mehr nicht.

Der ehrliche Restpunkt ist die SIM-Karte. Sie ist ein eigener kleiner Computer mit eigenem Prozessor, und der Carrier kann ihr über das Netz Befehle senden – eine Angriffsfläche, die in der Vergangenheit für gezielte Angriffe der „Simjacker"-Klasse genutzt wurde. Aber auch hier gilt: Das war zielgerichtet gegen Einzelpersonen, der mögliche Schaden beschränkte sich auf Standort und Geräte-Kennungen, und die SIM kann weder euren Speicher auslesen noch das Gerät lahmlegen. Wer das ausschließen will, kann die SIM entfernen oder das Gerät rein über WLAN betreiben.

Unterm Strich: „Massenhaftes Lahmlegen" ist nur als Netzabschaltung real – also als Dienstverweigerung, die jedes Gerät gleich trifft und niemandem Zugriff auf eure Daten gibt. Ein heimlicher, fern auslösbarer Modem-Killswitch, der gezielt eure Geräte brickt oder übernimmt, passt dagegen nicht ins signierte, isolierte Vertrauensmodell – und wäre, würde er existieren, durch genau die Forensik- und Netzwerkanalysen längst aufgefallen, die GrapheneOS so transparent machen.

Was der Provider sieht – und was verschlüsselt bleibt

Trennen wir sauber zwischen zwei Ebenen, denn auch hier wird viel durcheinandergeworfen.

Auf der Netzwerkebene sehen euer Mobilfunkanbieter und damit potenziell auch Behörden bestimmte Metadaten – und das gilt für jedes Mobiltelefon der Welt, völlig unabhängig vom Betriebssystem. Dazu gehören: in welche Funkzelle ihr eingebucht seid (und damit grob euer Standort), Verbindungszeitpunkte, Gesprächs- und SMS-Metadaten und mit welchen IP-Adressen ihr sprecht. Das ist Physik und Funktionsweise des Mobilfunknetzes, kein GrapheneOS-Versäumnis. Wer auch diese Metadaten reduzieren will, braucht ein VPN oder Tor – und für den Standort gegenüber dem Provider hilft letztlich nur, das Gerät auszuschalten oder ohne SIM zu betreiben.

Auf der Inhaltsebene sieht hingegen weder der Provider noch das Modem den Klartext eurer Kommunikation. Moderne Verbindungen sind Ende-zu-Ende oder zumindest per TLS verschlüsselt. Selbst ein bösartiges Modem oder ein neugieriger Provider bekommt verschlüsselten Datenstrom zu sehen, keinen lesbaren Inhalt. Die viel zitierte Angst „die sehen alles" verwechselt Metadaten mit Inhalten. Wer mitliest, dass ihr mit einem Server gesprochen habt, weiß noch lange nicht, was ihr gesagt habt.

Was Wireshark tatsächlich zeigt

Damit zum Wireshark-Argument, das oft falsch herum erzählt wird. Behauptet wird, Mitschnitte würden beweisen, dass Google über das Modem alles einsieht. Tatsächlich zeigen Netzwerkanalysen das Gegenteil.

Wer den Datenverkehr eines GrapheneOS-Geräts mitschneidet, stellt fest: Es gibt keine ständigen Verbindungen zu Google-Servern. Ohne Play Services telefoniert das System nicht nach Hause. Konnektivitätsprüfungen und Update-Abfragen gehen an die Server von GrapheneOS, nicht an Google. Dienste, die unter Stock-Android über Google laufen würden, fehlen schlicht. Ein Mitschnitt belegt also nicht die Überwachung, sondern ihre Abwesenheit – er zeigt ein System, das eben gerade nicht permanent Telemetrie streamt.

Was ein Mitschnitt nicht leisten kann, ist ein Blick in die proprietäre Modem-Firmware selbst. Aber genau deshalb ist die IOMMU-Isolation so wichtig: Sie sorgt dafür, dass das, was ihr nicht vollständig auditieren könnt, auch nicht beliebig auf den Rest des Systems zugreifen kann. Ihr müsst dem Modem nicht blind vertrauen – ihr sperrt es ein.

Der empirische Beweis: der Cellebrite-Leak

An dieser Stelle hört die Theorie auf und werden die Fakten unbequem für die Mythos-Erzähler. Wenn Google über die Hardware „vollen Zugriff" auf Pixel-Geräte hätte, dann müsste sich diese Annahme in der Praxis zeigen – und sie tut genau das Gegenteil.

Ende 2025 tauchten geleakte Unterlagen der Forensik-Firma Cellebrite auf. Cellebrite baut jene Werkzeuge, mit denen Strafverfolgungsbehörden weltweit gesperrte Smartphones auslesen. Die durchgesickerte „Support-Matrix" listet auf, welche Geräte und Zustände sich knacken lassen. Das Ergebnis: Pixel-Geräte mit Stock-Android lassen sich in bestimmten Zuständen zumindest teilweise auslesen – dieselben Pixel-Geräte mit GrapheneOS dagegen widerstehen den Werkzeugen weitgehend. Für GrapheneOS-Versionen ab Ende 2022 fand Cellebrite den Unterlagen zufolge keinen funktionierenden technischen Zugang.

Lasst diesen Punkt kurz sacken. Dieselbe Google-Hardware. Einmal mit Googles System, einmal mit GrapheneOS. Das eine lässt sich teilweise auslesen, das andere stoppt eines der weltweit fortschrittlichsten Forensik-Systeme. Das ist der direkte, empirische Beleg dafür, dass nicht der Hardware-Hersteller den Zugriff kontrolliert, sondern das Betriebssystem.

Und es entlarvt die „Google-Backdoor"-These gleich doppelt: Erstens würde keine Behörde teure Cellebrite-Lizenzen kaufen, gäbe es einen bequemen Hintereingang über Google. Zweitens würde so ein Hintereingang die Pixel-Geräte auch nicht ausgerechnet dann scheitern lassen, wenn GrapheneOS darauf läuft.

Ehrlich bleiben: nichts ist zu 100 Prozent sicher

Genau diese Ehrlichkeit gehört zu einer seriösen Einordnung dazu, und wir machen euch hier nichts vor. Absolute Sicherheit gibt es nicht. Es existieren Exploits, auch gegen gehärtete Systeme. Baseband-Schwachstellen, Zero-Click-Angriffe der Pegasus-Klasse, physischer Zugriff mit Spezialhardware – das alles ist real.

Entscheidend ist aber die Natur dieser Angriffe. Sie sind:

teuer, oft im Bereich von Millionenbeträgen pro Ziel; spezialisiert und individualisiert, also auf eine konkrete Person zugeschnitten; häufig an bestimmte Bedingungen geknüpft, etwa physischen Zugriff oder einen bestimmten Gerätezustand; und sie sind nicht skalierbar. Man kann sie gegen einzelne, hochrangige Ziele richten, aber nicht gegen die gesamte Bevölkerung gleichzeitig ausrollen.

Genau das ist der Kern: Massenüberwachung und gezielte Kompromittierung sind zwei verschiedene Bedrohungsmodelle. Massenüberwachung lebt von automatisierter, flächendeckender Datensammlung – und genau die schaltet GrapheneOS aus, indem es Telemetrie, Google-Dienste und Sammelschnittstellen entfernt. Gezielte Angriffe bleiben theoretisch möglich, kosten aber pro Person so viel Aufwand, dass sie niemand breit einsetzt.

GrapheneOS reduziert sogar diese Restfläche aktiv: durch hardwarebasiertes Memory Tagging, einen gehärteten Speicherallokator, einen automatischen Neustart in den besonders geschützten Zustand vor der ersten Entsperrung nach längerer Inaktivität, abschaltbares USB bei gesperrtem Gerät, einen LTE-only-Modus zur Verkleinerung der Modem-Angriffsfläche und vieles mehr. Wer sein Bedrohungsmodell kennt, kann hier sehr weit drehen.

Fazit

Die Behauptung „Google hat über das Pixel ohnehin vollen Zugriff" hält keiner technischen Prüfung stand. Verified Boot verriegelt das Gerät auf eure Schlüssel, nicht auf Googles. Ohne Play Services und Telemetrie fällt die gesamte Infrastruktur für Massendatensammlung weg. Das Modem ist per IOMMU isoliert und kommt nicht beliebig an euren Speicher. Netzwerk-Mitschnitte belegen die Abwesenheit von Google-Verbindungen, nicht deren Existenz. Und der Cellebrite-Leak liefert den empirischen Schlussstein: Auf identischer Hardware schlägt GrapheneOS die Forensik, Stock-Android nicht.

Was bleibt, ist die ehrliche Wahrheit, die für jede Technik gilt: Es gibt keine absolute Sicherheit. Aber der Unterschied zwischen „theoretisch durch einen teuren, gezielten Angriff verwundbar" und „permanent flächendeckend überwacht" ist gewaltig. GrapheneOS verschiebt euch klar in die erste Kategorie. Für nahezu jedes realistische Bedrohungsmodell ist ein Pixel mit GrapheneOS damit nicht „Verarsche", sondern eine der stärksten Kombinationen, die ihr heute kaufen könnt. Wer mehr über GrapheneOS erfahren will, kommt mal hier vorbei, oder liest unseren ausführlichen GoS Guide und findet heraus, dass die Bedienungen sich von einem normalen Android Smartphone kaum unterscheidet.

The post Hat Google Zugriff auf Pixel Phones mit GrapheneOS appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Artikel ordnen wir für euch ein, was genau angekündigt wurde, warum die ersten Geräte trotzdem erst 2027 kommen, welche knallharten Hardware-Anforderungen dahinterstecken – und warum „GrapheneOS löst sich von Google" eine Schlagzeile ist, die nur zur Hälfte stimmt.

Was auf dem MWC 2026 angekündigt wurde

Anfang März 2026 hat Motorola auf dem Mobile World Congress in Barcelona eine langfristige Partnerschaft mit der GrapheneOS Foundation öffentlich gemacht. Damit wird Motorola – das seit Jahren zu Lenovo gehört – der erste Hardware-Hersteller außerhalb von Google, der GrapheneOS offiziell unterstützt. Bis dahin standen ausschließlich Google-Pixel-Geräte auf der Liste der unterstützten Hardware, aktuell von der Pixel-6-Reihe bis zur Pixel-10-Serie.

Die offizielle Sprache klang erwartbar groß: Motorola will mit der Zusammenarbeit „modernste Sicherheit für Alltagsnutzer weltweit" liefern. Hinter den Marketingfloskeln steckt aber ein konkreter technischer Plan. Es geht nicht darum, GrapheneOS irgendwie auf bestehende Moto-Telefone zu zwingen. Stattdessen entwickelt Motorola künftige Geräte von Grund auf so, dass sie die strengen Anforderungen des Projekts erfüllen. GrapheneOS hat zusätzlich angedeutet, dass Motorola auch einige GrapheneOS-Funktionen in die eigenen Geräte integrieren wird.

Im Fokus stehen zunächst die Flaggschiff-Linien: die nächste Generation des Motorola Signature, das Razr Fold und das Razr Ultra. GrapheneOS hat klargestellt, dass der Fokus anfangs auf einem einzigen Gerät liegt und sich die Unterstützung danach schrittweise auf weitere Modelle ausweiten kann. Wer also schon träumt, sein bestehendes Razr 2026 zu flashen: Das wird nicht passieren. Es geht ausdrücklich um künftige, eigens dafür konstruierte Hardware.

Warum erst 2027? Das Problem heißt Memory Tagging

Die ehrliche Antwort auf die naheliegende Frage „Warum dauert das so lange?" ist technisch und liegt nicht an Bürokratie, sondern an Silizium. GrapheneOS verlangt von künftigen Geräten Hardware Memory Tagging, eine der wirkungsvollsten Exploit-Mitigationen, die es derzeit auf mobilen Plattformen gibt. Und genau diese Funktion ist bei der Konkurrenz zu Googles Tensor-Chips lange ein Schwachpunkt gewesen.

Memory Tagging (auf ARM heißt das Memory Tagging Extension, kurz MTE) markiert Speicherbereiche mit einer Art Etikett und prüft bei jedem Zugriff, ob das Etikett des Zeigers zum Etikett des Speichers passt. Ganze Klassen von Speicherfehlern – Use-after-free, Buffer-Overflows – werden damit zur Laufzeit abgefangen, statt sie zur Angriffsfläche werden zu lassen. Auf den Pixels ab der 8. Generation läuft das längst standardmäßig, weil diese Geräte auf neue ARMv9-Kerne setzen. GrapheneOS nutzt Memory Tagging per Default, um das Basissystem und kompatible Apps zu schützen.

Bei Qualcomm, dessen Snapdragon-Chips Motorola verbaut, war funktionierendes Memory Tagging lange nicht durchgängig verfügbar. Erst mit dem Snapdragon 8 Elite Gen 5 implementiert Qualcomm das Feature vollständig. Genau deshalb hat GrapheneOS das ursprünglich angepeilte Fenster von „Ende 2026 oder 2027" inzwischen klar auf 2027 verschoben. Das Projekt hat bestätigt, dass die künftigen Nicht-Pixel-Geräte definitiv auf Snapdragon setzen werden – vermutlich auf das Flaggschiff-SoC, das gegen Ende 2026 erscheint – und dass die Unterstützung je nach Implementierung durch Qualcomm und Motorola mehrere Geräteklassen umfassen könnte.

Mit anderen Worten: Die Partnerschaft wartet darauf, dass die Hardware reif wird. Das ist kein Rückschlag, sondern Ausdruck dessen, dass GrapheneOS bei seinen Sicherheitsstandards nicht verhandelt.

Was GrapheneOS von Hardware verlangt – und warum nur Pixel sie bisher erfüllt

Damit ihr versteht, warum dieser Schritt so lange auf sich warten ließ, lohnt sich ein Blick auf den Anforderungskatalog. GrapheneOS beschränkt seine offizielle Unterstützung nicht aus Bequemlichkeit auf Pixel-Geräte, sondern weil bislang nur diese das komplette Paket liefern. Dazu gehören mehrere Bausteine, die ineinandergreifen:

Hardware Memory Tagging als Laufzeitschutz gegen Speicherkorruption, wie oben beschrieben. Dies ist der aktuelle Engpass auf Qualcomm-Seite.

Verified Boot mit relockbarem Bootloader. Das Gerät muss sich nach dem Flashen eines alternativen Betriebssystems wieder verriegeln lassen, sodass die gesamte Boot-Kette kryptografisch geprüft wird. Viele Hersteller erlauben entweder gar kein Entsperren des Bootloaders – oder ein erneutes Verriegeln nach Custom-ROM-Installation ist nicht möglich. Beides ist für GrapheneOS ein Ausschlusskriterium.

Ein isoliertes Secure Element mit Attestation. Pixel-Geräte bringen den Titan-M2-Chip mit, der einen StrongBox-Keystore samt hardwaregestützter Attestation bereitstellt. Dazu kommt die sogenannte Weaver-Funktion, die Brute-Force-Angriffe auf den Sperrcode durch erzwungene Verzögerungen praktisch unmöglich macht.

Isolierte Funk-Komponenten (Baseband-Isolation), damit ein kompromittiertes Modem nicht das ganze System gefährdet.

Verbindliche, mehrjährige Update-Garantien. Pixels der 8. Generation und neuer garantieren mindestens sieben Jahre Sicherheitsupdates ab Marktstart. Ein Sicherheits-Betriebssystem ist wertlos, wenn die Firmware-Basis darunter nach zwei Jahren keine Patches mehr bekommt.

Aktuelle Motorola-Geräte erfüllen diese Kriterien noch nicht – weder beim Verified Boot noch bei der Secure-Element-Isolation noch bei der Update-Kadenz. Genau das ist der Kern der Partnerschaft: Motorola baut nicht ein bestehendes Telefon um, sondern entwickelt neue Hardware, die diese Latte von Anfang an reißt.

Ein Detail dürfte die Privacy-Community besonders freuen: GrapheneOS hat angedeutet, dass die künftige Hardware physische Kill-Switches für Sensoren bekommen könnte – also echte Hardware-Schalter, um etwa Mikrofon oder Kameras stromlos zu schalten. Ein oft gewünschtes, bei Mainstream-Flaggschiffen aber praktisch nie umgesetztes Feature.

„GrapheneOS löst sich von Google" – die Schlagzeile, die nur halb stimmt

Hier wird es wichtig, genau hinzusehen, denn die populäre Erzählung verkürzt zwei verschiedene Dinge zu einem.

Erstens: GrapheneOS verabschiedet sich nicht von den Pixels. Das Projekt hat mehrfach bestätigt, dass die Pixel-Unterstützung auf absehbare Zeit weiterläuft. Solange Motorolas zertifizierte Geräte nicht ausgeliefert sind, bleiben aktuelle Pixels die einzige produktiv unterstützte und empfohlene Hardware. Wer heute ein GrapheneOS-Telefon braucht, kommt am Pixel nicht vorbei. Die Motorola-Partnerschaft erweitert die Hardware-Auswahl, sie ersetzt Google-Hardware nicht über Nacht.

Zweitens – und das ist der eigentlich spannende Punkt: Der schärfste Konflikt zwischen GrapheneOS und Google läuft längst nicht mehr über die Hardware, sondern über die Verifikation von Geräten. Google und Apple drängen mit Mechanismen wie der Play Integrity API und mobiler Attestation darauf, dass Webdienste und Apps nur noch „zertifizierten" Geräten vertrauen. Ein Pixel mit GrapheneOS und relocktem Bootloader ist objektiv sicherer als die meisten Stock-Android-Geräte – wird von manchen Banking-Apps und Webdiensten aber trotzdem ausgesperrt, weil es nicht den von Google abgesegneten Software-Stempel trägt. GrapheneOS wirft Google und Apple deshalb vor, unter dem Deckmantel der Betrugsbekämpfung in Wahrheit die Wahlfreiheit einzuschränken und alternative Betriebssysteme aus dem Netz zu drängen.

Die Pointe: Ein eigener oder ein zweiter Hardware-Lieferant löst dieses Attestation-Problem nicht automatisch. Aber er gibt GrapheneOS mehr Unabhängigkeit von einem einzelnen Anbieter, dessen geschäftliche Interessen denen des Projekts zunehmend zuwiderlaufen. Eine Diversifizierung der Hardware-Basis ist strategisch genau deshalb wichtig: Wenn Google morgen entscheidet, das Entsperren des Bootloaders zu erschweren oder die Pixel-Sicherheitsgarantien zu verwässern, hängt GrapheneOS nicht mehr an einem einzigen Faden.

Insofern ist „Abkehr von Google" als Richtungsangabe richtig, als Zustandsbeschreibung aber verfrüht. GrapheneOS baut sich ein zweites Standbein – die Pixels bleiben vorerst das erste.

Was das konkret für euch bedeutet

Aus all dem lassen sich ein paar nüchterne Empfehlungen ableiten, ohne dass wir euch etwas vormachen müssen:

Wenn ihr jetzt ein GrapheneOS-Gerät wollt, kauft ein unterstütztes Pixel. Die späten Modelle der Pixel-Reihe sind ausgereift, dokumentiert und vom Projekt empfohlen. Auf ein Motorola zu warten, das frühestens 2027 erscheint, ergibt nur Sinn, wenn ihr ohnehin keinen Zeitdruck habt.

Kauft kein aktuelles Motorola in der Hoffnung, es später flashen zu können. Die Partnerschaft betrifft ausschließlich künftige, eigens konstruierte Geräte. Kein heute erhältliches Moto-Telefon erfüllt die GrapheneOS-Anforderungen, und nachträglich wird sich daran nichts ändern.

Wartet auf konkrete Fakten, bevor ihr für 2027 plant. Bislang gibt es weder bestätigte Modellnamen noch öffentlich dokumentierte Chip-SKUs mit funktionierendem Memory Tagging und relockbarem Bootloader. Die Strategie ist klar, die Spezifikationen sind es nicht. Wenn die ersten Geräte erscheinen, gilt dasselbe wie immer: erst die offizielle GrapheneOS-Bestätigung und unabhängige Tests aus der Community abwarten, dann kaufen.

Einordnung: Privacy wird langsam Mainstream

Der eigentliche Wert dieser Nachricht liegt weniger im einzelnen Gerät als im Signal. GrapheneOS meldete im April 2026 rund 400.000 aktive Nutzer – eine Schätzung, die das Projekt aus den Zugriffsprotokollen seiner Update-Server ableitet, weil es bewusst keinerlei Telemetrie ins Betriebssystem einbaut. Für ein Non-Profit-Projekt ohne Marketing-Budget und ohne Werbung ist das eine bemerkenswerte Reichweite.

Dass mit Motorola ein etablierter, zu Lenovo gehörender Hersteller bereit ist, Hardware nach den kompromisslosen Standards eines Open-Source-Privacy-Projekts zu engineeren, war vor wenigen Jahren noch undenkbar. Es zeigt, dass datenschutzfreundliche mobile Computing-Lösungen den Sprung von der Nische in Richtung Mainstream schaffen. GrapheneOS hat zudem angedeutet, dass weitere Hersteller-Partnerschaften in Verhandlung sind – Namen bleiben während laufender Gespräche vertraulich, aber das Interesse mehrerer großer Android-OEMs ist da. Ein erklärtes Ziel ist dabei auch, Regionen besser abzudecken, in denen Pixel-Geräte schlecht verfügbar sind, etwa in Teilen Asiens und Afrikas.

Natürlich gibt es auch skeptische Stimmen. Teile der Community warnen vor Vendor-Lock-in, vor einem möglichen Aufweichen der GrapheneOS-Standards durch Kompromisse mit einem Großkonzern und vor der weiterhin ungewissen Zukunft der Pixel-Unterstützung, sollte Google seine Politik ändern. Diese Bedenken sind berechtigt und gehören zu einer ehrlichen Bewertung dazu. Belastbar beantworten lassen sie sich aber erst, wenn die ersten Geräte real existieren und sich an der Praxis messen lassen.

Fazit

Die Motorola-Partnerschaft ist die wichtigste strategische Nachricht in der jüngeren Geschichte von GrapheneOS. Sie durchbricht die jahrelange Pixel-Exklusivität, sie zwingt einen großen Hersteller dazu, Hardware nach echten Sicherheitsstandards zu bauen, und sie gibt dem Projekt eine zweite Basis jenseits von Google. Was sie nicht ist: ein sofortiger Bruch mit Google. Die Pixels bleiben vorerst das Rückgrat, das erste Motorola-Gerät kommt frühestens 2027, und das eigentliche Tauziehen mit Google läuft ohnehin auf der Ebene der Geräte-Attestation, nicht der Hardware allein.

Für euch heißt das: Wer Privatsphäre und Sicherheit auf dem Smartphone ernst nimmt, hat heute mit einem Pixel und GrapheneOS die beste verfügbare Kombination – und ab 2027 womöglich eine echte Alternative dazu. Wir behalten die Entwicklung für euch im Blick und melden uns, sobald es konkrete Geräte und unabhängige Tests gibt.

The post GrapheneOS ohne Google Pixel appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dank des eingebauten WiFi-Mikrocontrollers (ESP32-S3) lässt sich die NerdQaxe einfach in euer Netzwerk integrieren und mit eurem bevorzugten Mining-Pool verbinden. Der Quellcode der Firmware sowie der Hardware ist offen und kann auf GitHub eingesehen werden. Genau das macht die Nerd*-Reihe so spannend: maximale Transparenz und Anpassbarkeit für alle, die mehr Mining-Leistung auf dem Schreibtisch haben möchten.

Welche NerdQaxe passt zu mir? Die Modelle im Überblick (2026)

Die Nerd*-Familie deckt alles vom kompakten Einzelchip-Miner bis zum Achtfach-Boliden ab. Die Modelle unterscheiden sich vor allem in der Anzahl der ASIC-Chips und damit in Hashrate und Stromverbrauch. Hier die gängigen Varianten im Vergleich:

Der BM1370 ist derselbe hocheffiziente Chip, der auch in Bitmains Antminer der S21-Pro-Generation steckt – entsprechend gut sind Hashrate und Effizienz. Für die meisten ist die NerdQaxe++ der Süssepunkt: viel Leistung bei hervorragender Effizienz und noch handlicher Lautstärke. Wer das absolute Maximum will, greift zur NerdOctaxe Gamma; wer klein und leise einsteigen möchte, ist mit der NerdAxe Gamma bestens bedient. Die Einrichtung ist bei allen Modellen praktisch identisch, da sie dieselbe Firmware nutzen.

Vorbereitungen und Voraussetzungen

Viel braucht ihr nicht, um loszulegen. Stellt vorab Folgendes bereit:

• Das mitgelieferte Netzteil (grössere Modelle wie die NerdOctaxe benötigen entsprechend mehr Leistung – nutzt immer das passende Netzteil).
• Ein 2,4-GHz-WLAN (der ESP32 funkt ausschliesslich auf 2,4 GHz, nicht auf 5 GHz).
• Eine eigene Bitcoin-Adresse, an die eure Mining-Belohnung ausgezahlt werden soll.
• Ein Smartphone oder einen Rechner mit Browser für die Erstkonfiguration.

Einrichtung und Anwendung der NerdQaxe

Gerät anschliessen

Schliesst das Netzteil an die NerdQaxe an und verbindet es mit einer Stromquelle. Das Gerät startet automatisch, sobald es mit Strom versorgt wird – einen separaten Einschaltknopf gibt es nicht.

Verbindung zum Access Point herstellen

Beim ersten Start spannt die NerdQaxe ein eigenes WLAN auf (Access Point). Sucht in euren WLAN-Einstellungen nach diesem Netzwerk – den genauen Namen (SSID) zeigt euch das Display des Geräts an. Verbindet euch damit; ein Passwort ist nicht nötig, da es sich um einen offenen Access Point handelt.

Konfiguration über das Captive Portal

Sobald ihr verbunden seid, öffnet sich automatisch ein Captive Portal (ähnlich wie in Hotels oder öffentlichen Netzwerken). Öffnet oben links das Burger-Menü und geht in die Settings. Zuoberst findet ihr die WLAN-Einstellungen: Tragt unter SSID den exakten Namen eures Heim- oder Geschäfts-WLANs ein. Achtet penibel auf Gross-/Kleinschreibung und alle Leerzeichen – stimmt hier etwas nicht, kann sich das Gerät nicht verbinden. Speichert mit SAVE und startet die NerdQaxe über das Interface mit RESTART neu. Bei korrekter Eingabe verbindet sie sich anschliessend mit eurem WLAN.

Zugriff auf das Dashboard

Um auf das Dashboard zuzugreifen, braucht ihr die IP-Adresse des Geräts – auch diese zeigt euch das Display an. Gebt sie genau so, wie sie dort steht, in die Adresszeile eures Browsers ein. Schon habt ihr vollen Zugriff auf die Weboberfläche der NerdQaxe.

Pool- und Wallet-Konfiguration

Im Dashboard findet ihr unter Settings die Pool-Einstellungen. Als Pool empfehlen wir unseren eigenen, gebührenfreien Blitzpool – tragt dazu blitzpool.yourdevice.ch auf Port 3333 ein. Das ist unser eigener Schweizer Solo-Mining-Pool. Ihr könnt natürlich jeden anderen Pool eurer Wahl nutzen; sollte der Hauptpool einmal nicht erreichbar sein, lohnt sich zusätzlich ein Fallback-Pool (Secondary Pool).

Unter Stratum User tragt ihr eure eigene Bitcoin-Adresse ein, damit die Belohnungen direkt an euch ausbezahlt werden. Als Passwort genügt ein beliebiger Wert (wird in der Regel nicht benötigt). Eure Statistiken könnt ihr jederzeit auf blitzpool.yourdevice.ch einsehen, indem ihr dort dieselbe BTC-Adresse eingebt. Übernehmt auch hier alle Änderungen mit SAVE und einem anschliessenden RESTART.

Stratum V1 oder V2

Neu könnt ihr in den Pool-Einstellungen zwischen Stratum V1 (SV1) und dem moderneren Stratum V2 (SV2) wählen. SV2 verschlüsselt die Verbindung zwischen Miner und Pool (Schutz vor Man-in-the-Middle-Angriffen), kommt mit deutlich weniger Datenverkehr aus und erlaubt es Minern perspektivisch, ihre Blockvorlage selbst zu bestimmen – ein wichtiger Schritt für mehr Dezentralisierung im Bitcoin-Netzwerk. Die Hintergründe haben wir im Beitrag Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht ausführlich erklärt.

Für SV2 benötigt ihr neben Host und Port zusätzlich den Authority Key (den Public Key des Pools). Zwei empfehlenswerte SV2-Pools:

• Blitzpool (unser Schweizer Solo-Pool, 0 %) – Host blitzpool.yourdevice.ch, Authority Key:
  9bCoFxTszKCuffyywH5uS5o6WcU4vsjTH2axxc7wE86y2HhvULU
  Die vollständigen Verbindungsdaten findet ihr auf blitzpool.yourdevice.ch/stratum-v2.
• Braiins Pool (gepoolt, die Entwickler von Stratum V2) – Host stratum-v2.braiins.com, Port 3336, Authority Key:
  u95GEReVMjK6k5YqiSFNqqTnKU4ypU2Wm8awa6tmbmDmk1bWt
  Aktuelle Werte stets in der offiziellen Braiins-Anleitung prüfen.

Übernehmt eure Auswahl wie gewohnt mit SAVE und einem anschliessenden RESTART. Im Zweifel funktioniert SV1 nach wie vor problemlos – SV2 ist die zukunftssichere, aber optionale Wahl.

Welchen Mining-Pool für die NerdQaxe wählen?

Mit einer NerdQaxe minet man in der Regel solo – ihr nehmt also an einer Art Lotterie teil: Die Chance, einen ganzen Block zu finden, ist gering, dafür erhaltet ihr im Erfolgsfall die komplette Block-Belohnung. Dank der höheren Hashrate der Nerd*-Modelle stehen eure Lose dabei etwas besser als mit einer einzelnen Bitaxe. Für das Solo-Mining haben sich diese Pools etabliert:

• Blitzpool – unser eigener Schweizer Public-Pool (auf Basis der quelloffenen Public-Pool-Software). 0 % Gebühren, übersichtliche Statistiken und dank Serverstandort Schweiz niedrige Latenz für CH/EU. Stratum: stratum+tcp://blitzpool.yourdevice.ch:3333
• eusolo.ckpool.org – die EU-Variante von Con Kolivas’ ckpool (eigener Server in der EU seit Ende 2024, dadurch deutlich geringere Latenz als das originäre solo.ckpool.org). 2 % Gebühr im Erfolgsfall.
• Public Pool – der originale, quelloffene Public-Pool. 0 % Gebühren und sogar selbst hostbar – genau die Software, auf der auch unser Blitzpool läuft.

Bevor ihr euch realistische Erwartungen setzt, lohnt sich ein Blick in unsere Beiträge Solo Mining – die grössten Fehlannahmen und Die kleine Bitcoin Solo Mining Bibel.

Mining starten

Sind die Pool-Einstellungen korrekt eingetragen, gespeichert und das Gerät neu gestartet, beginnt die NerdQaxe automatisch mit dem Mining – ein separater Startbefehl ist nicht nötig. In der vorkonfigurierten („preselected“) Variante sind Spannung und Frequenz der ASIC-Chips bereits sinnvoll optimiert, ihr müsst also nichts weiter einstellen, um loszulegen.

Monitoring und Wartung

Behaltet im Dashboard Temperatur und Hashrate im Auge. Die Temperatur sollte 75 °C nicht übersteigen. Reinigt das Gerät regelmässig, damit es nicht durch Staubansammlungen überhitzt. Wem der Lüfter zu laut ist, kann das Temperature Target z. B. auf 60 °C senken – der Lüfter dreht dann höher, was etwas mehr Strom zieht und das Gerät lauter macht. Umgekehrt sorgt ein höheres Target für leiseren, aber wärmeren Betrieb. So findet ihr euren persönlichen Kompromiss aus Lautstärke, Verbrauch und Temperatur.

Sicherheit und Updates

Halte die Firmware des Geräts auf dem neuesten Stand, um optimale Leistung und Sicherheit zu gewährleisten. Um auf neuere Versionen zu prüfen, nutzt du den automatischen Updater. Er zeigt, sobald eine neue Version verfügbar ist, und lässt dich diese mit einem klick auf Install from Github anwenden. Keep Settings behält deine aktuellen Einstellungen bei, der Haken sollte also drin bleiben.

Häufige Fragen zur NerdQaxe

Was ist der Unterschied zwischen NerdQaxe und Bitaxe?

Die Bitaxe nutzt einen einzelnen ASIC-Chip, die NerdQaxe-Modelle verbauen mehrere (vier bis acht). Dadurch liefern sie ein Vielfaches der Hashrate, sind aber grösser, lauter und verbrauchen mehr Strom. Bedienung und Firmware sind nahezu identisch – wer mit einer Bitaxe vertraut ist, findet sich sofort zurecht.

Welche NerdQaxe eignet sich für Einsteiger?

Für den Einstieg mit ordentlich Leistung ist die NerdQaxe++ die beliebteste Wahl: viel Hashrate bei hervorragender Effizienz. Wer es kompakter und leiser mag, startet mit der NerdAxe Gamma; wer das Maximum sucht, nimmt die NerdOctaxe Gamma.

Wie viel Strom verbraucht eine NerdQaxe?

Das hängt stark vom Modell ab: Eine NerdQaxe++ liegt je nach Taktung bei rund 70–90 Watt, eine NerdOctaxe Gamma mit acht Chips bei etwa 160–240 Watt. Über das Temperature Target und den „PowerSave“-Betrieb lässt sich der Verbrauch zugunsten der Effizienz feinjustieren.

Ist die NerdQaxe Open Source?

Ja. Sowohl das Hardware-Design als auch die AxeOS-basierte Firmware sind quelloffen und auf GitHub einsehbar. Damit reiht sich die NerdQaxe in die offene Bitaxe-/Nerd*-Philosophie ein – volle Transparenz statt Blackbox.

Fazit

Die NerdQaxe ist die logische Weiterentwicklung der Bitaxe für alle, die mehr Hashrate auf dem Schreibtisch haben möchten, ohne auf den Open-Source-Gedanken und die einfache Einrichtung zu verzichten. Dank vorkonfigurierter Firmware seid ihr in wenigen Minuten am Minen – idealerweise gleich in unserem gebührenfreien Blitzpool. Wer tiefer ins Thema einsteigen möchte, dem sei unsere kleine Bitcoin Solo Mining Bibel ans Herz gelegt.

Falls ihr auf der Suche nach einer NerdQaxe seid, schaut gerne bei uns im Shop vorbei – dort findet ihr die aktuellen Modelle von der NerdAxe Gamma bis zur NerdOctaxe Gamma.

The post NerdQaxe Einrichtung und Anwendung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Im Dezember 2017, mitten im damaligen Fee-Inferno, hat der Bitcointalk-Nutzer philipma1957 einen Thread aufgemacht, der für ordentlich Wirbel sorgte: "Why all miners need to mine on a pool that pays them the tx fees." Sein Vorwurf war drastisch. Die grossen Mining-Pools – BTC.com, Antpool, BTC.TOP, ViaBTC – würden die Transaktionsgebühren der gefundenen Blöcke einfach behalten. Und nicht nur das: Sie hätten dadurch sogar einen ökonomischen Anreiz, das Bitcoin-Netzwerk künstlich verstopft zu halten.

Wer den Thread heute liest, könnte denken, das sei ein Stück Bitcoin-Folklore aus einer wilderen Zeit. Heute zahlen doch alle grossen Pools FPPS, also Block Subsidy plus Fees, und die Welt ist in Ordnung – oder?

Wir wollen euch in diesem Artikel zeigen, warum philipmas Argument 2017 absolut korrekt war, warum es heute formal überholt wirkt, und warum der eigentliche Kern seiner Kritik trotzdem wichtiger ist denn je – nur an einer anderen Stelle. Stichwort: Coinbase-Hoheit.

Was philipma 2017 vorgerechnet hat

Die Mathematik in seinem Originalpost ist holprig formatiert, aber der Mechanismus dahinter ist sauber. Stark vereinfacht:

Ein Pool kontrolliert sagen wir 20 Prozent der Hashrate. Er findet pro Tag etwa 29 von 144 Blöcken. Die Block-Fees lagen Ende 2017 bei mehreren BTC pro Block. Wenn dieser Pool die Fees komplett für sich behält, statt sie an die Miner durchzureichen, sammelt er pro Tag eine satte Summe ein, von der seine Miner nichts sehen.

Jetzt kommt der eigentliche Trick: Wenn der Pool selbst Transaktionen sendet – egal ob legitime interne Auszahlungen oder gezielt produziertes Spam-Volumen – zahlt er für diese Transaktionen zwar Fees. Sobald er aber einen seiner eigenen Blöcke findet (und das passiert bei 20 Prozent Hashrate ja regelmässig), bekommt er die ausgelegten Fees vollständig zurück. Es entsteht ein anteiliger Refund auf alle eigenen Transaktionen, der grob mit dem Hashrate-Anteil des Pools skaliert.

Das Resultat: Der Pool kann das Netzwerk künstlich überlasten, treibt damit die Fee-Bid-Auktion für alle anderen Nutzer in die Höhe, und kassiert genau diese hochgetriebenen Fees am Ende selbst ein. Eine sich selbst finanzierende Spirale.

philipma nannte das ausdrücklich keine Block-Withholding-Attacke, sondern Fee Manipulation. Und er hatte einen klaren Aufruf: Verlasst die grossen PPS-Pools, geht zu Pools, die die Fees an euch durchreichen. Damals waren das vor allem Kano's Pool, ck's Pool, Jonny's Pool und P2Pool.

Warum der Vorwurf 2017 zutraf: PPS ohne Fee-Sharing

Der entscheidende Kontext, der heute oft vergessen wird: Ende 2017 fuhren Antpool und BTC.com schlichtes PPS – Pay Per Share. Das heisst, der Miner bekam einen festen Satz pro eingereichter Share, kalkuliert ausschliesslich auf Basis der Block Subsidy. Die Transaktionsgebühren? Blieben beim Pool. Punkt.

Das war damals technisch nicht einmal versteckt, sondern offizielle Auszahlungspolitik. Bei einer Block Reward von 12,5 BTC und Subsidy-only-PPS hat der Pool schlicht den Anteil ignoriert, der über die Subsidy hinausging. In ruhigen Zeiten waren das ein paar Prozent extra. Im Dezember 2017, als die Mempool-Fees regelmässig 5, 6, 8 BTC pro Block ausmachten, bedeutete das aber, dass der Pool plötzlich zwischen 30 und 50 Prozent der gesamten Block-Einnahmen für sich behielt, ohne dass das in den ausgewiesenen Pool-Fees auftauchte.

Pools wie Kano's Pool haben das schon damals anders gemacht. PPLNS, niedriger Fee, Fees gehen anteilig an die Miner, fertig. Genau das war der Boykott-Aufruf, der durch den Thread ging.

Was sich seitdem geändert hat: Die FPPS-Welle

Die Verbreitung von FPPS hat ab 2018 eingesetzt – und das war keine moralische Erleuchtung der Pool-Betreiber, sondern eine knallharte Reaktion auf die Konkurrenz. Wenn die Miner anfangen, sich darüber Gedanken zu machen, wo ihre Fees bleiben, dann muss man als Pool ein Modell anbieten, in dem sie nicht mehr fragen müssen.

FPPS – Full Pay Per Share funktioniert so: Der Pool berechnet den langfristigen Durchschnitt der Block-Fees pro Block und schlägt diesen Anteil zusätzlich auf den PPS-Satz. Der Miner bekommt also einen festen Satz pro Share, der sowohl die Subsidy als auch die durchschnittliche Fee-Komponente abbildet. Variance-Glättung wie bei klassischem PPS, aber eben mit Fee-Anteil.

Heute fahren praktisch alle grossen Mining Pools FPPS oder eine Variante davon. Foundry USA, AntPool, F2Pool, ViaBTC, Binance Pool – alle. Wer als grosser Pool kein Fee-Sharing macht, verliert seine Miner. Nach dem Halving 2024 ist diese Frage sogar noch wichtiger geworden, weil die Block Subsidy nur noch 3,125 BTC beträgt und die Fee-Komponente einen immer grösseren Teil der Block-Einnahmen ausmacht.

In dem Sinne also: Der formale Kritikpunkt von 2017 ist heute weg. Wer auf einem modernen FPPS-Pool mined, bekommt seine Fees, wenn auch geglättet als Erwartungswert.

Aber – und das ist der eigentliche Punkt – das Problem hat sich nicht gelöst. Es hat sich nur verschoben.

Wo die Pool-Macht wirklich liegt: Die Coinbase-Transaktion

Stellt euch kurz vor, wie das Mining im Detail abläuft. Der Pool baut das Block-Template. Der Pool entscheidet, welche Transaktionen aus dem Mempool in den Block kommen. Der Pool konstruiert die Coinbase-Transaktion, also die allererste Transaktion im Block, die das Geld an Empfangsadressen verteilt. Der Miner bekommt dieses fertige Template, hashed darauf herum, und meldet erfolgreiche Shares zurück.

Das heisst: Der Pool kontrolliert die komplette Coinbase-Konstruktion. Der Miner ist Hashing-Sklave, sonst nichts. Diese Architektur ist so alt wie Stratum V1 und sie ist der eigentliche Hebel, an dem Pool-Betreiber sitzen.

Was bedeutet das praktisch?

Out-of-Band-Payments

Ein Pool kann Transaktionen in seine Blöcke aufnehmen, die nie über den öffentlichen Mempool laufen. Stichwort Slipstream von Marathon, oder vergleichbare private Annahme-Kanäle. Ein Grosskunde zahlt direkt an den Pool, der Pool nimmt die Transaktion in den nächsten gefundenen Block auf, und der Miner sieht in der offiziellen Fee-Statistik – nichts. Die Coinbase zeigt brav die normale Fee-Summe, die Out-of-Band-Zahlung läuft komplett am FPPS-Modell vorbei.

Das ist die moderne Wiederauflage von philipmas Punkt: Es gibt Einnahmen, die der Pool generiert und die der Miner nicht sieht.

MEV und Block-Template-Optimierung

Sobald Bitcoin über reine Wertübertragungen hinaus mehr Komplexität bekommt – Ordinals, BRC-20, Inscriptions, Runes, was auch immer – entstehen Optimierungsmöglichkeiten beim Block-Bau, die nicht trivial sind. Ein Pool, der besonders smart Templates baut, kann pro Block mehr rausholen als ein einfacher Mempool-Sortierer. Diese Mehreinnahmen fliessen in die Pool-Kasse, nicht in den FPPS-Satz.

Zensur und Compliance

Wenn ein Pool aus regulatorischen Gründen bestimmte Transaktionen oder Adressen filtert, wird das auf der Coinbase-Ebene entschieden. Der Miner hat darauf keinen Einfluss. Es gab und gibt Phasen, in denen einzelne Pools nachweislich OFAC-konforme Templates gebaut haben. Aus Sicht des einzelnen Miners ist das eine politische Entscheidung, die er weder mit beschliesst noch direkt verhindern kann.

Empty Blocks

Schon 2017 ein Reizthema: Manche Pools haben gelegentlich leere Blöcke ausgeliefert, um die Latenz zwischen "neuer Block gefunden" und "neues Template verteilt" zu überbrücken. Bei jedem leeren Block werfen die Miner kollektiv ein paar BTC Fees zum Fenster raus. Der Pool hat darauf keinen Verlust – seine FPPS-Auszahlung ist konstant, der Verlust verteilt sich auf alle.

Der gemeinsame Nenner: Vertrauen statt Trustlessness

Was alle diese Phänomene verbindet: Der Miner liefert die Hashrate, aber der Pool entscheidet, was damit gehasht wird. Solange diese Trennung besteht, bleibt der Miner auf Vertrauen angewiesen. Vertrauen, dass der Pool den FPPS-Satz fair kalibriert. Vertrauen, dass keine Out-of-Band-Streams an ihm vorbeilaufen. Vertrauen, dass er nicht plötzlich Teil einer Zensur-Strategie wird, die er nicht unterschreiben würde.

Bitcoin ist als trustless-System konzipiert. Aber genau an der Pool-Schnittstelle ist diese Trustlessness 15 Jahre lang löchrig geblieben.

Die echte Lösung: Stratum V2 und DATUM

Hier wird es konstruktiv. Es gibt seit ein paar Jahren ernsthafte Bewegung in Richtung einer Architektur, in der genau diese Coinbase-Hoheit beim Miner landet, wo sie aus ideologischer Sicht hingehört.

Stratum V2 geht das Problem grundsätzlicher an. Der zentrale Baustein hier ist der Job Declarator. Der Miner kann sein eigenes Block-Template signalisieren, der Pool akzeptiert es (oder lehnt es nach klar definierten Regeln ab) und der Hashing-Loop beginnt. Daneben bringt Stratum V2 verschlüsselte Verbindungen, binary Framing statt JSON, deutlich effizientere Header-Übertragung, und – wichtig für ehrliche Pools – eine technische Trennung zwischen Hashrate-Buchhaltung und Template-Kontrolle.

DATUM (Decentralized Alternative Templates for Universal Mining), entwickelt von Ocean, ist ein Protokoll, bei dem der Miner sein Block-Template selbst baut – inklusive selbstgewählter Coinbase-Adressen. Der Pool macht nur noch zwei Dinge: Er aggregiert Hashrate-Beiträge zur Variance-Glättung, und er sorgt dafür, dass die Auszahlung über PPLNS oder ähnliche Modelle fair verteilt wird. Welche Transaktionen im Block landen und wem die Coinbase die Subsidy zuteilt, entscheidet der Miner.

In Kombination führen DATUM und Stratum V2 dazu, dass die alte philipma-Frage – "behält der Pool meine Fees?" – auf einer anderen Ebene beantwortet wird. Nicht durch Vertrauen in den FPPS-Satz, sondern durch architektonische Entkopplung. Der Pool kann die Fees gar nicht mehr unterschlagen, weil die Coinbase nicht mehr seine ist.

Was das für eure Pool-Wahl bedeutet

Wir bauen mit Blitzpool genau aus diesem Grund einen der ersten Stratum-V2-basierten Solo-Mining-Pools. Solo-Mining ist dabei nur der Einstiegspunkt – die Architektur ist so gedacht, dass der Pool-Betreiber strukturell nicht in die Position kommt, an der Coinbase zu manipulieren. Der Bitcoin-Empfang der Subsidy läuft non-custodial, die Block-Templates werden mit Transparenz produziert, und die Auszahlung ist nachvollziehbar.

Das ist kein Marketing-Geschwätz. Das ist die direkte technische Antwort auf eine Kritik, die jetzt fast neun Jahre alt ist und in ihrem Kern nie wirklich adressiert wurde.

Für euch als Miner heisst das konkret: Bei der Pool-Wahl reicht es nicht mehr, "FPPS, klingt fair" als Kriterium zu nehmen. Ihr solltet euch mindestens drei Fragen stellen:

1. Macht der Pool Out-of-Band-Payments oder gibt es eine Aussage, dass er das ausschliesst?
2. Welche Stratum-Version fährt der Pool? Wer Stratum V2 mit Job Declaration unterstützt, gibt die Coinbase-Hoheit zumindest teilweise an euch zurück.
3. Wie sieht die Zensur-Politik aus? Gibt es Compliance-Filter? Sind sie dokumentiert?

Wer dazu keine klaren Antworten findet, verlässt sich – wie 2017 – am Ende doch wieder nur auf das Wort des Pool-Betreibers.

Fazit: Der alte Thread war seiner Zeit voraus

Wenn ihr den 2017er Thread heute lest, lacht nicht über die Mathematik. philipma hat etwas gesehen, was die meisten damals nicht sehen wollten: Dass die Anreizstruktur zwischen Pool und Miner schief ist. Dass ein Pool, der mehr Macht hat als ein reines Hashrate-Aggregat, diese Macht früher oder später ausnutzen wird, einfach weil der Markt ihn dazu zwingt.

Die FPPS-Welle hat den damals offensichtlichen Symptompunkt – fehlendes Fee-Sharing – formal geheilt. Aber die zugrundeliegende Trennung zwischen "Hashrate liefern" und "entscheiden, was gehasht wird" ist geblieben. Und solange sie bleibt, ist die Frage, ob die Miner ihre Einnahmen vollständig sehen, eine Vertrauensfrage – nicht eine technische.

DATUM, Stratum V2, Job Declaration und Solo-Pools wie Blitzpool sind die Werkzeuge, mit denen sich dieses Vertrauen in Architektur überführen lässt. Das ist nicht der schnelle Weg. Es ist nicht der bequeme Weg. Aber es ist der einzige, der die ursprüngliche philipma-Frage – "warum behält jemand anderes meine Fees?" – wirklich beantwortet, statt sie nur zu verstecken.

Wer ernsthaft am Bitcoin-Mining beteiligt ist, sollte sich die Frage stellen, auf welcher Seite dieser Entwicklung er stehen will. Bei den grossen Pools, die im Hintergrund Out-of-Band-Geschäfte machen und FPPS als Glättungsschleier benutzen? Oder bei einer Mining-Infrastruktur, die das Versprechen "trustless" ernst nimmt – auch und gerade an der Stelle, wo Pool und Miner aufeinandertreffen?

Wir wissen, wo wir stehen. Und der gute alte Thread aus dem Dezember 2017 hat bis heute mehr Recht, als seinen Autoren damals lieb gewesen sein dürfte.

FAQ: Bitcoin Mining Pool Gebühren und Fee-Sharing

Was bedeutet FPPS bei Bitcoin Mining Pools? FPPS steht für Full Pay Per Share. Der Pool zahlt euch einen festen Satz pro Share aus, der sowohl Block Subsidy als auch durchschnittliche Transaktionsgebühren abbildet. Das macht eure tägliche Auszahlung planbar, blendet aber Sondereinnahmen wie Out-of-Band-Payments aus.

Was ist der Unterschied zwischen FPPS und PPLNS? FPPS glättet die Auszahlung über einen kalkulatorischen Erwartungswert und schiebt das Glücksrisiko zum Pool. PPLNS (Pay Per Last N Shares) zahlt nur, wenn der Pool tatsächlich einen Block findet, dafür typischerweise mit niedrigeren Pool-Gebühren und ohne kalkulatorische Glättung der Fees.

Bekomme ich auf einem FPPS-Pool wirklich alle Transaktionsgebühren? Nicht zwangsläufig. Ihr bekommt den durchschnittlichen Erwartungswert der öffentlich sichtbaren Block-Fees. Out-of-Band-Payments, MEV-Optimierungen und ähnliche Sondereinnahmen fliessen meistens nicht in den FPPS-Satz ein.

Was ist die Coinbase-Transaktion? Die Coinbase-Transaktion ist die erste Transaktion in jedem Bitcoin-Block. Sie erzeugt die neuen Bitcoin aus der Block Subsidy und verteilt sie zusammen mit den Transaktionsgebühren. Wer die Coinbase-Transaktion baut, kontrolliert, wohin das Geld fliesst.

Was bringt Stratum V2 für Miner? Stratum V2 erlaubt es Minern, ihre eigenen Block-Templates zu bauen, statt sie blind vom Pool zu übernehmen. Damit liegt die Entscheidung über Transaktionsauswahl und Coinbase-Konstruktion beim Miner, nicht mehr beim Pool. Dazu kommen verschlüsselte Verbindungen und effizienteres Protokoll-Framing.

Ist DATUM dasselbe wie Stratum V2? Nein. DATUM ist ein eigenständiges Protokoll von Ocean, das auf ähnliche Ziele hinarbeitet (minerseitige Block-Templates, non-custodial Auszahlung). Stratum V2 ist die offiziellere Branchen-Initiative. Beide adressieren das Coinbase-Hoheit-Problem.

Was ist ein Non-Custodial Mining Pool? Ein Mining Pool, der eure Mining-Erträge nie selbst verwahrt. Stattdessen wird die Auszahlung direkt aus der Coinbase-Transaktion des gefundenen Blocks an die Miner verteilt. Damit entfällt das Gegenparteirisiko gegenüber dem Pool-Betreiber.

The post Stratum V2 und die Coinbase-Hoheit: Wem gehören eure Bitcoin Mining Fees appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Es kommt, wie es die „Schwurbler" vor langer Zeit vorausgesehen haben: Eine App zur Alters- und Identitätsverifikation, damit ihr überhaupt noch Zugriff aufs Internet bekommt. Und alles natürlich nur zum Schutze der Kinder. Wer damals gewarnt hat, wurde als paranoid belächelt. Heute ist die App da – und es läuft ziemlich genau so, wie die Skeptiker es prophezeit haben.

Das Ganze hat einen unangenehmen Beigeschmack von Animal Farm. Auch dort hiess es am Anfang, die neuen Regeln seien zum Schutz aller Tiere nötig. Niemand solle sich Sorgen machen, die Schweine wüssten schon, was sie täten. Später standen sie dann auf zwei Beinen und sahen aus wie die Menschen, gegen die sie ursprünglich angetreten waren. Wer heute „zum Schutz der Kinder" staatliche ID-Infrastruktur auf jedes Gerät schrauben will, erzählt strukturell dieselbe Geschichte – nur mit WLAN.

Erinnert ihr euch noch an die grossen Worte? „Technisch ausgereift." „Höchste Datenschutzstandards der Welt." „Open Source, jeder kann den Code prüfen." Genau das hat Ursula von der Lügen am Mittwoch, dem 16. April 2026, über die frisch vorgestellte EU-App zur Altersverifikation verkündet. Einen Tag später war das Ding kaputt. Ursula Von der Lügen steht dann noch stolz da und faselt etwas von "Kinderschutz sei Aufgabe der Eltern", doch präsentiert eine App, die diese Kontrolle genau den Eltern entreisst. Ich komme mir immer mehr vor wie im falschen Film.

Der britische Sicherheitsberater Paul Moore hat sich den Code tatsächlich angeschaut – so, wie man das bei Open Source halt machen darf. Er hat zwei Minuten gebraucht. Zwei. Minuten.

Was die EU-Entwickler gebaut haben

Damit ihr eine Vorstellung bekommt, über welches Qualitätsniveau wir hier reden:

• Die PIN liegt verschlüsselt auf dem Gerät – aber die Verschlüsselung ist nicht an den Identitätsspeicher gekoppelt. Wer ein paar Werte in der Konfigurationsdatei löscht und die App neu startet, kann eine neue PIN vergeben und behält trotzdem Zugriff auf die vorher hinterlegten Identitätsdaten. Mit anderen Worten: Ein Minderjähriger erstellt einmal einen verifizierten Altersnachweis, ein Erwachsener übernimmt die PIN – fertig ist der Schwarzmarkt für „über 18"-Tokens.
• Der Zähler für fehlgeschlagene PIN-Eingaben liegt als simpler Wert in derselben, editierbaren Konfigurationsdatei. Brute-Force-Schutz? Einfach den Zähler auf Null setzen. Wiederholen bis die PIN passt.
• Die biometrische Authentifizierung lässt sich mit einem einzigen true → false komplett abschalten.
• Secure Enclave auf iOS oder Trusted Execution Environment auf Android? Fehlanzeige. Die Hardware-Sicherheitsmodule, die seit Jahren in jedem Smartphone stecken und exakt für solche Aufgaben gebaut wurden, wurden nicht verwendet. Stattdessen: Klartext-Konfigurationsdatei. Ernsthaft.

Moores Kommentar dazu: Dieses Produkt wird irgendwann der Auslöser für eine massive Datenpanne sein. Es sei nur eine Frage der Zeit.

Das sind die Leute, die über eure Identität entscheiden wollen

Haltet euch das kurz vor Augen: Dieselbe EU, die euch erklärt, dass ihr euer Alter künftig digital nachweisen müsst, bevor ihr das Internet benutzen dürft – dieselbe EU, die mit der EUDI-Wallet den europaweiten Identitäts-Hub aufbaut, an den später Zahlungen, Führerschein, Krankenkasse und irgendwann wahrscheinlich euer Einkaufsverhalten angeflanscht werden – diese EU liefert als Referenz-Implementierung einen Prototyp, der an den grundlegendsten Konzepten der Mobile-App-Security scheitert.

Keine Hardware-Sicherheit. Editierbare Config-Files für sicherheitskritische Zustände. Brute-Force-Schutz, den man mit einem Texteditor aushebelt.

Das sind keine subtilen Fehler, die nur Spezialisten entdecken. Das ist das Niveau eines Security-Kurses aus dem ersten Semester. Und genau diese Leute wollen, dass ihr eurer Regierung, eurem Betriebssystem-Hersteller und einer Handvoll Grossunternehmen eure biometrischen Daten und eure Identität anvertraut. Jedes Mal, wenn ihr etwas online tun wollt.

Das Muster ist immer dasselbe

Zur Erinnerung: Discord wurde im September 2025 am Kundendienst gehackt – dabei gingen Scans von Ausweisen und Führerscheinen der Nutzer flöten. Genau das, was Altersverifikations-Gesetze jetzt noch flächendeckender einfordern. Im Februar 2026 haben 405 Sicherheitsforscher aus aller Welt einen offenen Brief unterschrieben, der exakt vor diesen Szenarien warnt. Gebracht hat es: nichts.

Jede Altersverifikation, jedes Identitätssystem, jede zentrale Datensammlung, die in den letzten Jahren eingeführt wurde, ist früher oder später gebrochen worden. Das ist keine Verschwörungstheorie, das ist Empirie. Und trotzdem bekommen wir jedes halbe Jahr ein neues System präsentiert, das dieses Mal ganz sicher sicher ist. Ehrlich. Versprochen.

Was ihr tun könnt

Jedes zusätzliche Verifikationssystem, das ihr ablehnt, ist ein Sieg. Jeder Dienst, den ihr durch eine selbstgehostete Alternative ersetzt, ist ein Datenpunkt weniger, den sie verlieren können. Jedes GrapheneOS statt Stock-Android, jedes Linux statt Windows, jeder Matrix-Server statt WhatsApp – das sind keine paranoiden Spielereien, das ist praktische Selbstverteidigung in einem Umfeld, in dem die Gegenseite nachweislich nicht weiss, was sie tut.

Die EU-Altersverifikations-App war zwei Minuten lang sicher. Zwei Minuten. Fragt euch, wie lange die EUDI-Wallet halten wird, wenn es ernst wird.

Wer freie Software, GrapheneOS-Geräte oder selbstgehostete Infrastruktur sucht: yourdevice.ch hilft weiter.

Quelle: Tarnkappe.info – EU-App zur Altersüberprüfung in zwei Minuten gehackt!

The post Zwei Minuten. So lange hielt die EU-Altersverifikations-App appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Ausgangslage

Ein Acer Aspire, Dualboot-Wunsch eines Kunden: Windows soll bleiben, Linux Mint kommt dazu. Die Installation läuft sauber durch, Secure Boot war aktiviert mit MOK-Enrollment, alles wie es sein soll. Der Installer meldet Erfolg, Neustart, und... Windows bootet direkt. Kein GRUB, kein Bootmenü, kein gar nichts. Als wäre Linux nie installiert worden.

Im BIOS nachgeschaut: Kein Linux-Eintrag vorhanden. (würde im übrigen"ubuntu" heissen, auch wenn Mint installiert ist — das ist der interne Name, den der Shim-Bootloader nutzt.) Nur Windows Boot Manager.

Also gut, nochmal. Mint-Stick rein, neu installiert, diesmal ganz genau auf alles geachtet: EFI-Partition korrekt gemountet, Bootloader-Installation auf die richtige Platte, MOK-Enrollment sauber durchgezogen. Installer meldet wieder Erfolg. Neustart. Windows.

Okay, dann eben manuell. Live-Stick booten, per chroot ins installierte System einhängen, GRUB neu installieren:

sudo mount /dev/nvme0n1p5 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

Alles läuft fehlerfrei durch. Ein Blick auf die EFI-Partition bestätigt: GRUB liegt sauber in /EFI/ubuntu/, shimx64.efi, grubx64.efi, grub.cfg — alles da, wo es hingehört. Mit efibootmgr -v einen Eintrag manuell angelegt. Alles sieht gut aus.

Neustart. Windows.

Wieder ins BIOS: Der Eintrag, den wir gerade mit efibootmgr erstellt haben, ist weg. Einfach nicht da. Wir legen ihn nochmal an, Neustart — wieder weg. Das Ganze ein paar Mal wiederholt, in der Hoffnung, dass wir irgendwo einen Fehler machen. Falsche Hoffnung.

An diesem Punkt — nach drei Neuinstallationen, mehreren chroot-Sessions und gefühlt einem Dutzend efibootmgr-Aufrufen — haben wir angefangen zu recherchieren, ob es da vielleicht ein bekanntes Problem gibt.

Was wir fanden, war ernüchternd.

Das Problem: Acer und das NVRAM

Einige ältere und auch neuere Acer-Modelle haben eine ziemlich spezielle UEFI-Firmware, die bei jedem Boot alle EFI-Boot-Einträge, die nicht von Microsoft stammen, einfach aus dem NVRAM löscht. Das ist kein Bug, das ist quasi "as designed". Ihr könnt efibootmgr hundertmal ausführen, die Einträge sind beim nächsten Boot wieder weg.

Ein bekanntes Problem, das seit Jahren in diversen Foren dokumentiert ist. Und genau der Grund, warum ich später unten noch ein paar Worte dazu verlieren werde.

Der Workaround: GRUB als Windows tarnen

Wenn das BIOS nur Microsoft-Einträge akzeptiert, dann machen wir GRUB eben zu Microsoft. Die Idee: Wir ersetzen die Windows-Bootloader-Datei bootmgfw.efi durch GRUB. Das BIOS denkt, es startet Windows, startet aber in Wahrheit GRUB, und von dort aus können wir dann sowohl Linux als auch Windows booten.

Schritt 1: Live-Stick booten

Von einem Linux-Live-Stick booten (Mint, Ubuntu, SystemRescue — egal). Bei Acer müsst ihr beim Einschalten F12 drücken, um ins Boot-Menü zu kommen, und dort den Stick auswählen.

Kleiner Hinweis aus eigener Erfahrung: Falls ihr vorher schon eine Linux-Installation versucht habt und ihr jetzt beim Booten vom Stick eine Fehlermeldung wie Failed to open \EFI\BOOT\mmx64.efi - Not Found bekommt, dann sitzen noch kaputte MOK-Variablen im NVRAM. In dem Fall hilft oft ein Stick ohne Shim (z.B. SystemRescue) oder Ventoy.

Schritt 2: EFI-Partition mounten

Im Live-System ein Terminal öffnen und die EFI-Partition mounten. Mit lsblk oder sudo fdisk -l herausfinden, welche Partition die EFI-Partition ist (meist eine kleine ~500MB FAT32-Partition, oft /dev/nvme0n1p1 oder /dev/sda1).

sudo mkdir -p /mnt/efi
sudo mount /dev/nvme0n1p1 /mnt/efi
ls /mnt/efi/EFI/

Ihr solltet dort mindestens Microsoft und einen ubuntu-Ordner sehen (bei Mint heisst er auch ubuntu).

Schritt 3: Windows-Bootloader sichern

Ganz wichtig: Bevor ihr irgendwas überschreibt, die originale Windows-Bootloader-Datei sichern. Ohne Backup kommt ihr nicht mehr an Windows ran.

sudo cp /mnt/efi/EFI/Microsoft/Boot/bootmgfw.efi /mnt/efi/EFI/Microsoft/Boot/bootmgfw.efi.bak

Schritt 4: GRUB als Windows-Bootloader einsetzen

Jetzt kopieren wir GRUB an die Stelle, wo Windows eigentlich seinen Bootloader hat:

sudo cp /mnt/efi/EFI/ubuntu/shimx64.efi /mnt/efi/EFI/Microsoft/Boot/bootmgfw.efi

Falls ihr Secure Boot nicht nutzt oder den Shim-Stress vermeiden wollt, geht auch direkt GRUB:

sudo cp /mnt/efi/EFI/ubuntu/grubx64.efi /mnt/efi/EFI/Microsoft/Boot/bootmgfw.efi

Schritt 5: GRUB-Konfiguration anpassen

Damit GRUB nachher auch Windows als Boot-Option anzeigt, müssen wir ihm sagen, wo der echte (gesicherte) Windows-Bootloader liegt. In die /etc/grub.d/40_custom auf eurem Linux-System (per chroot oder nach dem ersten erfolgreichen GRUB-Boot) folgendes einfügen:

menuentry "Windows 10/11" {
    insmod part_gpt
    insmod fat
    insmod chain
    search --no-floppy --fs-uuid --set=root <UUID-der-EFI-Partition>
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi.bak
}

Die UUID bekommt ihr mit sudo blkid. Danach:

sudo update-grub

Schritt 6: Neustart

Neustart, und siehe da: GRUB erscheint, ihr könnt Linux und Windows auswählen, die Welt ist wieder in Ordnung.

Was ihr wissen solltet: Der Hack ist fragil

Das Ganze ist, ehrlich gesagt, eine Frickelei. Es funktioniert, aber es hat zwei Schwachstellen, die ihr kennen solltet:

Normale Kernel-Updates sind unkritisch. Ein apt upgrade mit Kernel-Update ruft intern nur update-grub auf, das ändert nur die grub.cfg und lässt die EFI-Dateien in Ruhe. Hier müsst ihr nichts befürchten.

Aufpassen bei grub-install. Wenn das Paket grub-efi-amd64 selbst aktualisiert wird (kommt selten vor) oder ihr grub-install manuell ausführt, dann schreibt GRUB seine EFI-Datei wieder brav nach /EFI/ubuntu/ und der getarnte Windows-Pfad wird nicht aktualisiert. Schlimmstenfalls bootet danach wieder Windows direkt und ihr müsst die Datei erneut nach /EFI/Microsoft/Boot/bootmgfw.efi kopieren.

Windows-Updates sind das grössere Risiko. Kumulative Updates sind meist unproblematisch, aber grössere Feature-Updates (z.B. jährliche Hauptversionen) können bootmgfw.efi durch den echten Windows-Bootloader ersetzen. Dann ist GRUB weg und ihr bootet wieder direkt in Windows. Fix: Live-Stick, nochmal kopieren.

Tipp: Legt euch ein kleines Skript an, das die GRUB-Datei wieder an den Microsoft-Pfad kopiert. Spart euch im Notfall Tipperei.

Warum Acer aus unserem Shop geflogen ist

An dieser Stelle wird es vielleicht klar, warum ihr in unserem Shop keine Acer-Geräte mehr findet. Solche Sonderlocken im BIOS, kaputte MOK-Handling, NVRAM-Einträge die einfach gelöscht werden — das ist genau der Stress, den wir uns, und unseren Kunden nicht zumuten wollen. Wer ein Linux-Gerät kauft, soll es auspacken, einschalten und damit arbeiten können. Nicht stundenlang EFI-Dateien durch die Gegend kopieren oder BIOS-Quirks recherchieren.

Deswegen setzen wir auf Hersteller wie Lenovo, HP und Asus, bei denen Linux zuverlässig und ohne Frickelei läuft. Das erspart uns und euch eine Menge Kopfschmerzen. Günstige Acer-Modelle mögen auf den ersten Blick verlockend aussehen, aber die versteckten Kosten in Form von Zeit und Frust rechnen sich am Ende einfach nicht.

Fazit

Wenn ihr einen älteren Acer habt und Linux nebenher installieren wollt, kommt ihr um diesen Workaround oft nicht herum. Er funktioniert, aber er ist ein Hack, kein sauberer Dualboot. Wer Linux stressfrei nutzen möchte, greift beim nächsten Laptop-Kauf lieber zu einer Marke, bei der das BIOS einfach seinen Job macht — und nicht versucht, Linux aktiv auszusperren.

Habt ihr ähnliche Erfahrungen mit Acer gemacht? Schreibt es gerne in die Kommentare.

The post Acer und Linux: Wenn das BIOS den Bootloader einfach löscht appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was an Stratum V1 nicht mehr funktioniert

Stratum V1 hat Bitcoin-Mining gross gemacht. Aber es wurde zu einer Zeit entworfen, in der das gesamte Netzwerk einen Bruchteil der heutigen Hashrate hatte. Die Schwächen sind inzwischen offensichtlich:

Keine Verschlüsselung. Jede Kommunikation zwischen Miner und Pool läuft im Klartext. Internet-Provider, Netzwerkbetreiber und Angreifer können Shares mitlesen, die Hashrate eines Miners abschätzen und – im schlimmsten Fall – durch sogenannte Man-in-the-Middle-Angriffe die Pool-Credentials austauschen und Hashrate umleiten. Das ist keine theoretische Gefahr: In Regionen mit staatlicher Internetüberwachung ist das ein reales Risiko.

Ineffiziente Datenübertragung. Stratum V1 nutzt JSON als Nachrichtenformat. Das ist menschenlesbar, aber für Maschinen unnötig aufgebläht. Jede Share-Submission, jede Job-Zuweisung schleppt Overhead mit sich, der Bandbreite und CPU-Zyklen kostet. Für einen einzelnen Miner im Keller kein Problem – für Farmen mit tausenden Geräten oder Miner in Regionen mit eingeschränkter Internetverbindung sehr wohl.

Der Pool bestimmt alles. Das ist der vielleicht gravierendste Punkt. Bei Stratum V1 entscheidet ausschliesslich der Pool, welche Transaktionen in einen Block aufgenommen werden. Die Miner liefern Rechenleistung, haben aber keinerlei Einfluss auf den Inhalt der Blöcke, die sie produzieren. Das bedeutet: Eine Handvoll grosser Pools kontrolliert de facto die Transaktionsselektion des gesamten Netzwerks. Wenn ein Pool beschliesst, bestimmte Transaktionen nicht aufzunehmen – sei es aus politischem Druck, Compliance-Anforderungen oder wirtschaftlichem Kalkül – haben die Miner kein Mitspracherecht. Das ist ein Zentralisierungsrisiko, das dem Grundgedanken von Bitcoin diametral widerspricht.

Was Stratum V2 anders macht

SV2 wurde von Jan Čapek, Pavel Moravec und Matt Corallo entworfen und wird heute von einer unabhängigen Open-Source-Community weiterentwickelt. Die Stratum V2 Reference Implementation (SRI) ist in Rust geschrieben und steht jedem zur Verfügung.

Verschlüsselte Verbindungen. Jede SV2-Verbindung ist standardmässig mit dem Noise Protocol Framework verschlüsselt und authentifiziert. Das schützt vor Hashrate-Diebstahl, macht Traffic-Analyse durch ISPs nahezu unmöglich und verhindert, dass Dritte die Mining-Aktivität eines Teilnehmers überwachen oder manipulieren können.

Binäres Protokoll. Statt JSON verwendet SV2 ein schlankes Binärformat. Das reduziert die Bandbreite laut den Entwicklern um rund 60 % für Pools und 70 % für Miner. Zusätzlich sinkt die CPU-Last bei der Share-Validierung durch intelligentes Caching um bis zu 80 % gegenüber V1.

Job Declaration – Miner bestimmen den Blockinhalt. Das ist die eigentliche Revolution. Mit dem Job Declaration Protokoll können Miner ihre eigene Bitcoin-Node betreiben und selbst entscheiden, welche Transaktionen in ihren Block-Template landen. Der Miner deklariert seinen Vorschlag beim Pool, der Pool kann ihn akzeptieren – und falls nicht, kann der Miner automatisch auf einen anderen Pool oder Solo-Mining ausweichen. Damit wird die Transaktionsselektion dezentralisiert, und Pools verlieren die Möglichkeit zur Zensur.

Kompatibilität mit bestehender Hardware. Wer noch Geräte mit Stratum V1 Firmware betreibt, muss nicht auf SV2 verzichten. Ein sogenannter Translation Proxy (tProxy) sitzt zwischen dem SV1-Miner und dem SV2-Pool und übersetzt die Kommunikation in beide Richtungen. So können auch ältere ASICs wie die Bitaxe oder Antminer-Modelle sofort an einem SV2-Pool teilnehmen.

SV2-UI: In 5 Minuten Stratum V2 ausprobieren

Wer SV2 selbst testen möchte, ohne sich durch Rust-Kompilierungen und Konfigurationsdateien zu kämpfen, für den gibt es das SV2-UI – eine grafische Oberfläche, mit der ihr die gesamte SRI-Infrastruktur per Docker starten und konfigurieren könnt. Damit lässt sich unter anderem testen, wie ein SV1-Miner über den Translation Proxy an einen SV2-Pool angebunden wird.

Repository: https://github.com/stratum-mining/sv2-ui

Voraussetzungen

Auf eurem System muss Docker installiert und lauffähig sein. Das SV2-UI startet alle nötigen Komponenten als Container – ihr braucht weder Rust noch eine lokale Build-Umgebung. Ausserdem muss Bitcoin-Core auf eurem Rechner oder Server laufen. Am besten lässt man das ganze auf einem Minibolt Server laufen mit installiertem Bitcoincore.

Schnellstart

Öffnet ein Terminal und führt folgenden Befehl aus:

docker run --rm \
  --name sv2-ui \
  -p 8080:8080 \
  -e HOST_HOME=$HOME \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v sv2-config:/app/data/config \
  stratumv2/sv2-ui:v0.1.2

Anschliessend öffnet ihr http://localhost:8080 im Browser. Von dort aus könnt ihr die einzelnen SRI-Komponenten (Pool, Translation Proxy, Template Provider) starten, konfigurieren und überwachen. Dazu wird es aber noch einen eigenständigen Artikel geben. Der Translation Proxy lässt sich so konfigurieren, dass euer SV1-Miner darüber mit einem SV2-Pool verbunden wird – ohne dass die Firmware auf dem Gerät geändert werden muss.

Hinweis: Die Erstellung eigener Block-Templates über den Template Provider wird derzeit nur unter Linux unterstützt. Auf Windows ist diese Funktion noch in Arbeit.

SV2 nativ auf Bitaxe und NerdQAxe – Wir bauen die Firmware

Der Translation Proxy ist ein guter Zwischenschritt. Aber das eigentliche Ziel ist, dass Miner direkt SV2 sprechen – ohne Umweg, ohne zusätzliche Software. Genau daran arbeiten wir. Wir entwickeln aktiv an der nativen Stratum V2 Unterstützung für die ESP-Miner Firmware, die auf Bitaxe, NerdQAxe und anderen ESP32-basierten Mining-Geräten läuft.

Der Pull Request: github.com/bitaxeorg/ESP-Miner/pull/1553

Was steckt drin

Die Implementierung erweitert die bestehende ESP-Miner Codebasis um eine vollständige SV2-Protokollschicht – nicht als externe Abhängigkeit, sondern nativ in C, direkt neben dem bestehenden V1-Code. Im Detail:

SV2 Binärprotokoll. Frame-Encoding und -Decoding für das gesamte SV2 Binary Protocol. Die Firmware versteht alle zentralen Mining-Channel-Nachrichten: SetupConnection, OpenStandardMiningChannel, NewMiningJob, SetNewPrevHash, SetTarget und SubmitSharesStandard.

Noise-Verschlüsselung. Vollständige Noise_NX Handshake-Implementierung mit ChaCha20-Poly1305 Transport-Verschlüsselung über libsecp256k1. Die Verbindung zwischen Miner und Pool ist damit von der ersten Nachricht an verschlüsselt und authentifiziert – kein Klartext mehr auf der Leitung.

Protokoll-Auswahl in AxeOS. SV2 lässt sich direkt in der AxeOS-Weboberfläche aktivieren – sowohl für den primären als auch für den Fallback-Pool. Wer möchte, kann also Pool 1 auf SV2 und Pool 2 als V1-Fallback konfigurieren, oder beides auf SV2 setzen. Die Umschaltung läuft über den bestehenden NVS-Konfigurationsspeicher.

Getestet und funktional. Die Firmware wurde auf einem BM1370-basierten Bitaxe gegen einen lokalen SRI-Server und den SRI-Referenz-Pool getestet. Ergebnis: volle 1,3 TH/s Hashrate, Shares werden akzeptiert, verschlüsselte Verbindung steht. Das ist kein Proof of Concept – das funktioniert.

Welche Geräte werden unterstützt

Die ESP-Miner Firmware ist die gemeinsame Basis für eine ganze Familie von Open-Source-Minern. Alle Geräte, die auf dieser Firmware aufbauen, profitieren von der SV2-Integration:

Bitaxe (alle Varianten mit BM1366, BM1368, BM1370) – Die Geräte, die Solo-Mining für jedermann populär gemacht haben. Mit Hardware-Version-Rolling auf den neueren ASIC-Chips steht ein ausreichend grosser Suchraum für Standard Channels zur Verfügung.

NerdQAxe / NerdQAxe++ – Die Quad-ASIC-Varianten mit bis zu 4.8 TH/s. Auch hier läuft die ESP-Miner Firmware als Basis.

Weitere ESP32-basierte Miner – Jedes Gerät, das auf dem ESP-Miner Projekt aufbaut, kann die SV2-Firmware nutzen.

Was noch offen ist

Der Pull Request ist als Draft markiert – nicht weil die Grundfunktion fehlt, sondern weil einige Architekturentscheidungen noch im Review mit den ESP-Miner-Maintainern diskutiert werden:

Standard vs. Extended Channels. Aktuell sind nur auf der NerdQaxe++ nur Extented Channels implementiert. Der ältere BM1397 (Bitaxe Max) unterstützt kein Hardware-Version-Rolling, wodurch Standard Channels allein nicht ausreichen.

Selbst testen

Wer die SV2-Firmware auf der Bitaxe schon jetzt ausprobieren möchte, findet im Early Access Release vorkompilierte Binaries. Alternativ könnt ihr den Branch direkt aus dem Fork bauen. Verbinden tut ihr euch dann mit unserem vollständig SV2 kompatiblen Solo-Pool:

Host: blitzpool.yourdevice.ch
Port: 3333
Authority Public Key: 9bCoFxTszKCuffyywH5uS5o6WcU4vsjTH2axxc7wE86y2HhvULU
Netzwerk: Mainnet

Blitzpool – Einer der ersten SV2 Solo-Pools aus der Schweiz

Wer SV2 nicht nur testen, sondern produktiv nutzen möchte, kann sich unserem Blitzpool anschliessen. Blitzpool ist ein Schweizer Solo-Mining-Pool, der auf einem eigenen, vollständig synchronisierten Bitcoin-Core-Server läuft und aktiv an der Integration von Stratum V2 arbeitet.

Was Blitzpool von anderen Solo-Pools unterscheidet:

0 % Gebühren. Ihr erhaltet 100 % des Block-Rewards – ohne Abzüge. Keine versteckten Fees, kein Kleingedrucktes.

Keine Registrierung. Einfach die eigene Bitcoin-Adresse als Worker-Name eintragen und loslegen. Keine E-Mail, kein Account, keine persönlichen Daten.

Open Source. Der Pool-Code ist auf GitHub einsehbar und basiert auf einem stark erweiterten Fork des Public-Pool Projekts. Transparenz ist keine Option, sondern Standard.

SV2-Vorreiter. Blitzpool ist einer der ersten Solo-Pools, der aktiv Stratum V2 integriert. Damit können Miner nicht nur effizientere Verbindungen nutzen, sondern perspektivisch auch die volle Kontrolle über ihre Block-Templates zurückgewinnen.

Schweizer Infrastruktur. Der Pool wird in der Schweiz betrieben – mit den entsprechenden Vorteilen in Sachen Datenschutz und Rechtssicherheit.

Verbindungsdaten

Stratum Host: blitzpool.yourdevice.ch
Port: 3333
High-Difficulty Port: 3339

Tragt als Worker-Name einfach eure Bitcoin-Adresse ein. Optional könnt ihr mit einem Punkt getrennt einen Worker-Namen anhängen (z.B. bc1q...xyz.bitaxe01), um mehrere Geräte übersichtlich zu verwalten.

Mehr Informationen, Live-Statistiken und die Pool-Oberfläche findet ihr unter: https://blitzpool.yourdevice.ch

Fazit: Die Zeit für SV2 ist jetzt

Stratum V1 hat dem Bitcoin-Mining über ein Jahrzehnt lang gute Dienste geleistet. Aber die Probleme – fehlende Verschlüsselung, ineffiziente Kommunikation und die Zentralisierung der Transaktionsselektion – lassen sich nicht mehr ignorieren. Stratum V2 ist keine theoretische Verbesserung, sondern ein produktionsreifes Protokoll, das bereits von Herstellern wie Auradine nativ unterstützt und von der SRI-Community aktiv weiterentwickelt wird.

Mit der nativen SV2-Firmware für Bitaxe und NerdQAxe bringen wir das Protokoll dorthin, wo es hingehört: direkt auf die Geräte der Hobby-Miner. Kein Proxy, kein Umweg – einfach verschlüsseltes, effizientes Mining ab dem ersten Share. Zusammen mit Blitzpool als einem der ersten SV2-nativen Solo-Pools entsteht ein Setup, das von der Firmware bis zum Pool konsequent auf das neue Protokoll setzt.

Ob ihr SV2 erstmal mit dem SV2-UI ausprobieren, die neue Firmware auf eurer Bitaxe flashen oder direkt auf Blitzpool minen wollt – der Einstieg war nie einfacher. Jeder Miner, der auf SV2 umsteigt, stärkt die Dezentralisierung des Netzwerks. Und genau darum geht es.

Weiterführende Links:

• Stratum V2 Protokoll-Webseite: https://stratumprotocol.org
• SV2-UI (GUI für SRI): https://github.com/stratum-mining/sv2-ui
• SRI Reference Implementation: https://github.com/stratum-mining/stratum
• SV2 Applikationen (Pool, Translator, JD): https://github.com/stratum-mining/sv2-apps
• Blitzpool Solo-Mining Pool: https://blitzpool.yourdevice.ch
• Blitzpool auf GitHub: https://github.com/warioishere/blitzpool
• SV2-Firmware PR für ESP-Miner: github.com/bitaxeorg/ESP-Miner/pull/1553

The post Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Es ist ein Satz, der in der Netzpolitik mittlerweile zum geflügelten Wort geworden ist: „Won't somebody please think of the children?" Was als Simpsons-Gag begann, ist heute das Totschlagargument Nummer eins, wenn Regierungen weltweit neue Überwachungsinfrastruktur durchsetzen wollen. Die neueste Episode dieser Serie: Betriebssysteme sollen künftig euer Alter überprüfen. Nicht Websites. Nicht Apps. Euer Betriebssystem. Die Schicht eures Computers, der ihr am meisten vertrauen müsst.

Und wie immer geht es angeblich um den Schutz der Kinder.

Was passiert gerade

Was wie ein dystopischer Zukunftsentwurf klingt, ist längst Realität – oder steht unmittelbar bevor. Auf mehreren Kontinenten gleichzeitig treiben Regierungen Gesetze voran, die Betriebssysteme zur Altersverifikation zwingen. Die Begründung ist überall dieselbe: Jugendschutz. Die Methoden sind überall dieselben: digitale Identität, staatliche Schnittstellen, Kontrolle auf der tiefsten Ebene eurer Geräte. Und das Tempo, mit dem das geschieht, sollte euch zu denken geben. Hier ein Überblick über die Brennpunkte – angefangen bei dem Land, das wie so oft am gründlichsten vorgeht.

Deutschland: Der 6. Medienänderungsstaatsvertrag – bereits geltendes Recht

Deutschland wartet nicht auf Kalifornien oder die EU. Hier ist die Altersverifikation auf Betriebssystemebene bereits Gesetz.

Am 1. Dezember 2025 trat der Sechste Medienänderungsstaatsvertrag (6. MÄStV) in Kraft – beschlossen von den Ministerpräsidenten aller 16 Bundesländer. Das Herzstück: Ein neuer §12 JMStV mit dem unauffälligen Titel „Anforderungen an Anbieter von Betriebssystemen". Was harmlos klingt, hat es in sich. Erstmals in der Geschichte des deutschen Jugendmedienschutzes werden nicht mehr nur Medienanbieter in die Pflicht genommen, sondern die Technik selbst, mit der Medien konsumiert werden.

Konkret müssen Anbieter von Betriebssystemen eine sogenannte „Jugendschutzvorrichtung" implementieren – in der offiziellen Rhetorik verniedlichend als „One-Button-Lösung" bezeichnet. Die Idee: Eltern sollen „auf Knopfdruck" einen kinder- und jugendgerechten Modus aktivieren können, der den Zugang zu nicht altersgerechten Apps und Inhalten einschränkt. Das Betriebssystem muss dafür eine nicht veränderbare, einheitliche Schnittstelle bereitstellen, über die Apps die eingestellte Altersstufe auslesen. Apps, die keine Alterseinstufung haben, sind bei aktivierter Vorrichtung nicht nutzbar.

Der Zeitplan ist gestaffelt: Bis zum 1. Dezember 2026 bestimmt die Kommission für Jugendmedienschutz (KJM), welche Betriebssysteme als „von Kindern und Jugendlichen üblicherweise genutzt" gelten. Ein Jahr danach – also spätestens am 1. Dezember 2027 – müssen diese Betriebssysteme die Jugendschutzvorrichtung implementiert haben. Für Betriebssysteme im laufenden Produktionszyklus gibt es eine verlängerte Frist von drei Jahren.

Und hier wird es für die Open-Source-Welt richtig unangenehm: §24 JMStV definiert als Ordnungswidrigkeit nicht nur, wenn ein Betriebssystemanbieter die Jugendschutzvorrichtung nicht bereitstellt – sondern auch, wenn „ein Dritter" ein Betriebssystem so anpasst und bereitstellt, dass es über keine solche Vorrichtung mehr verfügt. Das zielt direkt auf Distributionen, die ein bestehendes Betriebssystem modifizieren und weiterverteilen – also genau auf das, was die Linux-Community seit Jahrzehnten tut. Verstösse können mit Bussen von bis zu 500.000 Euro geahndet werden.

Man muss sich das auf der Zunge zergehen lassen: Wer ein Linux-Derivat erstellt und den Jugendschutzmechanismus dabei nicht übernimmt, begeht nach deutschem Recht potenziell eine Ordnungswidrigkeit. Das ist ein direkter Angriff auf das Prinzip freier Software, verkleidet als Jugendschutz.

Die KJM bejubelt den 6. MÄStV als „Meilenstein für einen effektiven Kinder- und Jugendmedienschutz". Dass das Gesetz gleichzeitig neue Aufsichtsinstrumente einführt – darunter die Möglichkeit, Mirror-Domains schneller zu sperren und Zahlungsströme an unliebsame Anbieter zu unterbinden – erwähnt man eher beiläufig. Auch der neue Schutzbereich der „persönlichen Integrität" im §1 JMStV, der so weit gefasst ist, dass darunter auch „exzessives Spielen" und „Kostenfallen" fallen, zeigt, wohin die Reise geht: ein immer breiterer Eingriffshebel, der weit über Pornografie und Gewaltdarstellungen hinausreicht.

Doch Deutschland topt sich selbst auch auf Bundesebene: Das Jugendschutzgesetz (JuSchG) verpflichtet Plattformbetreiber seit 2021 zu „Vorsorgemaassnahmen", zu denen explizit Altersverifikationssysteme gehören. Die Bundesdruckerei arbeitet an der Infrastruktur für digitale Identitäten, und die SPRIND (Bundesagentur für Sprunginnovationen) koordiniert den Rollout der deutschen EUDI-Wallet-Version, die als „robuste erste Version" bis Ende 2026 stehen soll. Deutschland ist ausserdem eines der ersten Länder mit Pilotprogrammen für die EU-Altersverifikations-App.

Kein anderes Land in Europa hat ein derart durchreguliertes System – Jugendschutzgesetz auf Bundesebene, Jugendmedienschutz-Staatsvertrag auf Länderebene, KJM als Aufsichtsbehörde, FSM als Selbstkontrolle, jugendschutz.net als Überwachungsstelle, Landesmedienanstalten als Vollstrecker. Und jetzt kommt die Betriebssystemebene obendrauf. Der deutsche Regulierungseifer beim „Kinderschutz" ist ein bürokratisches Meisterwerk, das in seiner Tiefe weltweit einzigartig ist.

Kalifornien: Der US-Vorreiter

Im Oktober 2025 unterzeichnete der kalifornische Gouverneur Gavin Newsom den Digital Age Assurance Act (AB 1043). Das Gesetz tritt am 1. Januar 2027 in Kraft und verlangt, dass jeder Anbieter eines Betriebssystems bei der Kontoeinrichtung das Alter des Nutzers abfragt. Die Nutzer werden in vier Altersgruppen eingeteilt: unter 13, 13 bis 15, 16 bis 17 und ab 18. Diese Alterskategorie wird dann über eine Echtzeit-API an App-Entwickler weitergegeben – bei jedem Download, bei jedem Start einer Anwendung.

Die Definition von „Operating System Provider" im Gesetzestext ist dabei so breit gefasst, dass sie jeden betrifft, der ein Betriebssystem „entwickelt, lizenziert oder kontrolliert" – egal ob auf einem Computer, Smartphone oder einem beliebigen Gerät. Das schliesst Windows ein, macOS, Android, iOS – und eben auch Linux, SteamOS und sogar einen Open-Source-Taschenrechner namens DB48X, dessen Entwickler sich bereits geweigert haben, das Gesetz umzusetzen.

Colorado zieht mit einem ähnlichen Gesetzentwurf (SB26-051) nach. New York will die Pflicht sogar auf alle „internetfähigen Geräte" ausweiten. Und das ist erst der Anfang.

Grossbritannien: Der Online Safety Act und seine Folgen

Grossbritannien ist bereits einen grossen Schritt weiter – und zeigt der Welt in Echtzeit, wohin diese Reise führt.

Der Online Safety Act 2023 verpflichtet Plattformen, die pornografische Inhalte oder Material zu Selbstverletzung, Essstörungen und Suizid anbieten, zur Altersverifikation. Die Frist zur Umsetzung war der 25. Juli 2025. Die Aufsichtsbehörde Ofcom kann bei Verstössen Strafen von bis zu 18 Millionen Pfund oder zehn Prozent des Jahresumsatzes verhängen – und Websites im gesamten Vereinigten Königreich sperren lassen.

Die Reaktion der Plattformen kam prompt: Reddit, Discord, X (ehemals Twitter), Tinder, Bumble, Grindr, Hinge, Spotify und zahlreiche weitere Dienste führten Altersverifikationen ein – teilweise über Drittanbieter wie Yoti oder Persona. Dass es dabei nicht um Kinderschutz geht, zeigt sich an der öffentlichen Reaktion: Eine Petition zur Abschaffung des Gesetzes sammelte über 500.000 Unterschriften und erzwang eine Parlamentsdebatte. Am ersten Tag der Durchsetzung stiegen die VPN-Downloads im Vereinigten Königreich um über 1.400 Prozent. Nutzer umgingen die Gesichtserkennung von Persona mit Screenshots aus dem Videospiel Death Stranding.

Doch das genügt der Regierung nicht. Premierminister Keir Starmer treibt zusätzlich ein Social-Media-Verbot für unter 16-Jährige voran – nach australischem Vorbild. Im Februar 2026 kündigte er an, die Umsetzung solle „in Monaten, nicht Jahren" erfolgen. Eine öffentliche Konsultation läuft bis Mai 2026, Pilotversuche mit 300 Jugendlichen sind geplant. Das House of Lords hat den Vorschlag bereits zweimal unterstützt.

Und dann wurde es wirklich ernst: Ende März 2026 rollte Apple mit iOS 26.4 eine Altersverifikation auf Betriebssystemebene für alle britischen Nutzer aus. Beim Update werden Nutzer aufgefordert, per Kreditkarte oder Ausweis-Scan zu bestätigen, dass sie über 18 sind. Wer die Verifikation nicht abschliesst oder als minderjährig eingestuft wird, bekommt automatisch Inhaltsfilter aktiviert und eingeschränkten Zugang zu Apps, Websites und Funktionen. Das Ergebnis: Erwachsene Nutzer – manche seit Jahrzehnten Apple-Kunden, 60, 70, 80 Jahre alt – berichten, dass ihre Geräte eingeschränkt wurden, weil die Verifikation fehlschlug. Ein abgenutzter Ausweis, schlechte Beleuchtung beim Scannen, eine nicht akzeptierte Kreditkarte – und schon ist man auf seinem eigenen iPhone gesperrt. Ofcom bejubelte die Massnahme als „echten Gewinn für Kinder und Familien".

Die britische Regierung arbeitet parallel an einem eigenen digitalen Ausweis und konsultiert öffentlich, ab welchem Alter – möglicherweise schon ab 13 oder sogar ab Geburt – eine digitale ID ausgestellt werden soll. Die Electronic Frontier Foundation (EFF) kommentierte trocken, dass britische Politiker „weiterhin am Kern der Sache vorbeireden" und die Altersverifikation als „Überwachungs- und Zensur-Albtraum" bezeichneten.

Wikipedia hat bereits angekündigt, die Umsetzung zu verweigern und gegebenenfalls den Zugang für britische Nutzer einzuschränken, anstatt sein offenes Bearbeitungsmodell zu kompromittieren. Die Wikimedia Foundation nannte das Gesetz „hart" und warf den Gesetzgebern vor, nicht zwischen kommerziellen Tech-Giganten und gemeinnützigen Wissensprojekten zu unterscheiden.

Brasilien: Der Hammer fällt zuerst

Wer glaubt, das seien alles noch Pläne für die Zukunft, sollte nach Brasilien schauen. Dort ist das Gesetz seit dem 17. März 2026 in Kraft – und es ist das umfassendste seiner Art weltweit.

Das „Digital ECA" (Estatuto Digital da Criança e do Adolescente, Gesetz Nr. 15.211/2025) wurde im September 2025 von Präsident Lula unterzeichnet und gilt für jeden digitalen Dienst, der von Minderjährigen genutzt werden könnte – unabhängig davon, wo der Anbieter seinen Sitz hat. Die Selbstauskunft über das Alter ist ausdrücklich verboten. Plattformen müssen „zuverlässige und effektive" Verifikationsmechanismen einsetzen, und zwar bei jedem Zugriff auf eingeschränkte Inhalte. Konten von unter 16-Jährigen müssen an einen Erziehungsberechtigten gekoppelt werden.

Die Strafen sind drakonisch: Bis zu 50 Millionen Brasilianische Real (etwa 8,5 Millionen Euro) pro Verstoss oder bis zu zehn Prozent des brasilianischen Umsatzes. Die brasilianische Datenschutzbehörde ANPD hat eine Überwachungsliste veröffentlicht, auf der neben Epic Games und Valve auch Linux-Distributoren stehen. Rockstar Games hat den Direktverkauf über den eigenen Launcher in Brasilien bereits einen Tag vor Inkrafttreten eingestellt. Canonical prüft seine rechtlichen Verpflichtungen für Ubuntu.

Das Gesetz verlangt explizit, dass die Altersverifikation auf Ebene von App-Stores und Betriebssystemen bei der Kontoerstellung durchgeführt wird. Kein souveräner Staat hat jemals eine Altersverifikation auf Betriebssystemebene mit diesem Umfang und diesen Strafen vorgeschrieben.

Brasilien zeigt, was passiert, wenn diese Gesetze nicht mehr nur auf dem Papier stehen: Kleinere Anbieter kapitulieren, Open-Source-Projekte stehen vor unlösbaren Problemen, und die Nutzer werden in geschlossene Ökosysteme gezwungen, die sich kontrollieren lassen. MidnightBSD hat brasilianische Nutzer bereits komplett ausgesperrt.

Australien, Frankreich, Spanien – die Welle rollt

Australien hat Ende 2025 als erstes Land der Welt ein Social-Media-Verbot für unter 16-Jährige eingeführt – bereits Millionen Konten wurden gesperrt. Frankreich plant ein ähnliches Verbot ab 15 Jahren ab September 2026. Spanien, Griechenland und Slowenien haben eigene Verbote angekündigt. In Österreich ist ein Social-Media-Verbot ebenfalls beschlossen.

Es entsteht ein globaler Dominoeffekt: Jedes Land verweist auf die anderen als Begründung, warum es „auch" handeln muss. Und jedes dieser Gesetze erfordert – technisch zwingend – eine Form der Identitätsverifikation. Der „Kinderschutz" ist das Einfallstor; die digitale Ausweispflicht ist das Ergebnis.

Die EU baut die „Mini-Wallet"

Auf der anderen Seite des Atlantiks bastelt die EU-Kommission derweil an ihrer eigenen Lösung. Unter dem Dach des Digital Services Act und der überarbeiteten eIDAS-2.0-Verordnung wird die EUDI-Wallet (European Digital Identity Wallet) vorangetrieben – eine digitale Brieftasche, die bis Ende 2026 in jedem EU-Mitgliedstaat verfügbar sein soll. Darin gespeichert: Personalausweis, Führerschein, Gesundheitsdaten, Zeugnisse und – natürlich – eine Funktion zur Altersverifikation.

Doch weil die EUDI-Wallet nicht schnell genug kommt, hat die EU-Kommission bereits eine „Mini-Wallet" in Auftrag gegeben, entwickelt von T-Systems (Deutsche Telekom) und dem schwedischen Unternehmen Scytáles. Diese App hat genau eine Funktion: bestätigen, dass ihr über 18 seid. Eine Vorstufe zur digitalen Identität, die euch als EU-Bürger aufgezwungen werden soll.

Das Pikante daran: Es gibt in der EU aktuell kein Gesetz, das eine flächendeckende Altersverifikation für soziale Medien oder das Internet allgemein vorschreibt. Der Digital Services Act verpflichtet Plattformen lediglich zu „Schutzmassnahmen für Minderjährige" – die Altersverifikation ist eine von vielen möglichen Optionen, keine Pflicht. Trotzdem wird die technische Infrastruktur in atemberaubendem Tempo aufgebaut. Erst die Infrastruktur, dann das Gesetz – eine Reihenfolge, die aufmerksame Beobachter stutzig machen sollte.

Was in der offiziellen Kommunikation fehlt: eine ehrliche Diskussion darüber, wohin das alles führt.

Die Linux-Community wehrt sich

Die Open-Source-Gemeinschaft steht vor einem Dilemma. Während Microsoft, Apple und Google solche Abfragen mit einem Firmware-Update in ihre Systeme einbauen können, sieht die Lage bei Linux-Distributionen ganz anders aus.

Wer ist der „Operating System Provider" von Debian? Das Projekt ist keine juristische Person in den USA, es hat keinen CEO, keinen Sitz in Kalifornien. Es ist eine Meritokratie aus Freiwilligen, die auf der ganzen Welt verteilt sind. Und selbst wenn jemand eine Altersverifikation in Debian einbauen würde – freie Software bedeutet, dass jeder Nutzer diesen Code in fünf Minuten wieder entfernen kann. Weil Quellcode in den USA als freie Meinungsäusserung („Free Speech") gilt, kann das niemand verhindern.

In den Debian-Mailinglisten und Ubuntu-Foren wird seit Wochen heftig diskutiert. Ein konkreter technischer Vorschlag sieht eine D-Bus-Schnittstelle namens org.freedesktop.AgeVerification1 vor, die über Plug-Ins an staatliche Dienste andocken könnte. Die Reaktionen der Community waren überwiegend ablehnend. Es gibt auch Diskussionen über eine Integration in systemd, was unter Datenschützern die Alarmglocken schrillen lässt – ein einziger „Single Point of Failure" für sensible Altersdaten aller Systemnutzer.

GrapheneOS, das auf Privatsphäre und Sicherheit ausgerichtete Android-Derivat, hat bereits klar Stellung bezogen: Man werde die Altersverifikation schlicht ignorieren. Wenn das bedeutet, dass GrapheneOS-Geräte in bestimmten Märkten nicht mehr verkauft werden dürfen, sei das akzeptabel. Das System werde weiterhin für jeden weltweit nutzbar sein, ohne persönliche Daten, Identifizierung oder ein Konto.

Andere Open-Source-Projekte gehen noch weiter. Die Entwickler des Open-Source-Taschenrechners DB48X haben angekündigt, den Zugang für Nutzer in Kalifornien und Colorado zu sperren, anstatt eine Altersverifikation zu implementieren. Wie PC Gamer treffend anmerkte: „Ihr wisst, dass ihr es übertrieben habt, wenn ihr die Mathematiker wütend gemacht habt."

Das grössere Bild: Ein Netz der totalen Kontrolle

Nehmt einen Schritt zurück und betrachtet, was hier gleichzeitig auf der ganzen Welt passiert:

Apple setzt die Altersverifikation auf Betriebssystemebene bereits um – im Vereinigten Königreich per iOS 26.4, in Australien, Brasilien und Singapur für App-Downloads, und ab Mai 2026 in US-Bundesstaaten wie Utah und Louisiana über eine „Declared Age Range API" für Entwickler. Was heute „freiwillige Umsetzung" heisst, ist morgen der neue Standard.

Brasilien setzt die härtesten Strafen der Welt durch – mit Linux-Distributoren auf der Überwachungsliste der Datenschutzbehörde. Die Infrastruktur, die hier geschaffen wird, ist nicht temporär. Sie wird bleiben.

Die EUDI-Wallet soll bis Ende 2026 euren Personalausweis, Führerschein, Gesundheitsdaten, Zeugnisse und Versicherungsnachweise in einer App auf eurem Smartphone bündeln. Ab Ende 2027 müssen regulierte Branchen wie Banken, Gesundheitswesen und Telekommunikation die Wallet als Identifikation akzeptieren. Die EU hat als Ziel ausgegeben, dass bis 2030 achtzig Prozent aller Bürger eine digitale ID nutzen sollen.

Die Altersverifikation auf Betriebssystemebene schafft eine technische Infrastruktur, bei der euer Computer oder Smartphone bei jedem App-Start eure Alterskategorie weitergibt – eine Schnittstelle, die trivial auf eine vollständige Identitätsprüfung erweitert werden kann.

Secure Boot und Chain-of-Trust-Mechanismen werden von allen grossen Hardwareherstellern kontinuierlich ausgebaut. Schon heute können diese Systeme das Ausführen bestimmter Software verhindern. Es ist kein grosser Sprung, diese Werkzeuge mit einer digitalen Identität zu verknüpfen.

Chatkontrolle, Vorratsdatenspeicherung, Klarnamenpflicht – die EU und ihre Mitgliedstaaten arbeiten parallel an einem ganzen Arsenal von Überwachungswerkzeugen. Die Altersverifikation ist nur ein weiteres Puzzlestück. Und in Grossbritannien denkt man bereits laut darüber nach, Kindern die Nutzung von VPNs zu verbieten – also das letzte Werkzeug, mit dem man sich diesen Kontrollen entziehen könnte.

Ein Kommentator auf Born's IT-Blog brachte es auf den Punkt: „Heute nennen sie es noch ‚Altersüberprüfung', morgen wird es dann ‚Nutzung nur mit persönlicher digitaler ID' sein."

Wenn einmal ein Mechanismus flächendeckend auf allen Endgeräten vorhanden ist, mit dem sich der Zugang zu bestimmten Inhalten einschränken lässt, dann wird ihn jemand missbrauchen. Das ist keine Verschwörungstheorie – das ist die Geschichte jeder Überwachungstechnologie, die jemals gebaut wurde.

Die Heuchelei der Mächtigen

Und hier wird es richtig bitter. Dieselben Regierungen, die angeblich „die Kinder schützen" wollen, zeigen bei echtem Kindesmissbrauch eine bemerkenswerte Untätigkeit.

Die Epstein-Akten wurden Ende Januar 2026 in grossem Umfang veröffentlicht – über drei Millionen Seiten Dokumente, 2000 Videos und 180.000 Bilder. Das Material zeigt Verbindungen zu Politikern, Wirtschaftsführern und Persönlichkeiten des öffentlichen Lebens auf der ganzen Welt. Über tausend Opfer wurden dokumentiert, die meisten davon Minderjährige.

Und was geschah? Das US-Justizministerium erklärte, es gebe keine ausreichenden Beweise für weitere Anklagen. Das FBI erklärte, die Spekulationen über eine „Kundenliste" hätten sich nicht erhärtet. Die Akten selbst erzählen eine andere Geschichte – voller Namen, E-Mails, Fotos und Verbindungen. In den USA gab es bislang keine einzige weitere Verhaftung. Im Bundestag wurde die Debatte über deutsche Bezüge zu den Epstein-Akten an den Auswärtigen Ausschuss überwiesen – also faktisch begraben.

Es wird also eine gigantische digitale Überwachungsinfrastruktur aufgebaut, mit der jeder Bürger identifiziert und kategorisiert werden soll – alles im Namen des Kinderschutzes. Aber wenn es darum geht, die mächtigsten und dokumentiertesten Kinderschänder der modernen Geschichte tatsächlich zur Rechenschaft zu ziehen, dann hat plötzlich niemand genug Beweise. Die Prioritäten könnten kaum deutlicher sein.

Warum das alles nicht funktioniert – und nie funktionieren sollte

Abgesehen von der offensichtlichen Überwachungsproblematik scheitert die Altersverifikation auf Betriebssystemebene auch an ihrer eigenen Logik:

Kinder lügen. Das kalifornische Gesetz verlangt nur eine Selbstauskunft – kein Foto-ID, keine Biometrie. Ein Zwölfjähriger gibt „18" ein, und das System hat seinen Zweck erfüllt. Bravo.

Erwachsene werden ausgesperrt. Das Vereinigte Königreich zeigt bereits in der Praxis, was passiert: Erwachsene iPhones-Nutzer – manche über 80 Jahre alt, seit Jahrzehnten Apple-Kunden – werden durch fehlerhafte Altersverifikation auf ihren eigenen Geräten eingeschränkt. Ein abgenutzter Ausweis, schlechtes Licht, eine falsche Kreditkarte – und plötzlich entscheidet Apple, welche Inhalte man sehen darf.

Eltern umgehen es. Wenn Eltern ihrem Kind Zugang zu einem Computer geben, der auf ihren Namen registriert ist, hilft keine Altersverifikation der Welt. Die Verantwortung wird von den Plattformbetreibern in die Haushalte verlagert – und dort ändert sich nichts.

Standort-Erkennung ist ein Witz. Soll Debian die Altersverifikation in Kalifornien erzwingen, aber in der Schweiz deaktivieren? Basierend auf welcher Information? Der Nutzer gibt bei der Installation „Schweiz" an, und das Thema hat sich erledigt. Oder er nutzt ein VPN.

Freie Software lässt sich nicht kontrollieren. Quellcode ist Meinungsfreiheit. Jeder kann eine Distribution forken und die Altersverifikation entfernen. Das Gesetz ist gegenüber freier Software strukturell wirkungslos.

Verifizierungsdaten werden gehackt. Im Herbst 2025 wurden bei Discord 70.000 Ausweiskopien geleakt, nachdem ein Drittanbieter, der die Altersverifikation durchführte, kompromittiert wurde. Das ist kein theoretisches Risiko – es ist bereits Realität. Und je mehr Dienste Ausweisdaten sammeln, desto mehr Angriffsfläche entsteht.

Das alles wissen die Gesetzgeber natürlich. Der Jugendschutz ist der Vorwand, nicht das Ziel.

Warum Technik keine Kinder erzieht – und der Staat es auch nicht kann

Hinter all diesen Gesetzen steht eine Grundannahme, die niemand laut hinterfragt: Dass der Staat besser wüsste als Eltern, wie man Kinder vor den Gefahren des Internets schützt. Dass ein Algorithmus, eine API-Schnittstelle, eine Ausweiskontrolle auf Betriebssystemebene irgendwie das leisten könnte, was ein Gespräch am Küchentisch leistet. Das ist nicht nur technisch naiv – es ist eine Anmassung.

Viele von uns, die heute in der Tech-Welt arbeiten, sind mit dem Internet aufgewachsen. Wir haben als Jugendliche IRC-Channels besucht, in Foren Dinge gelesen, die nicht für uns bestimmt waren, und auf Websites gelandet, die kein Jugendschutzfilter der Welt hätte vorhersehen können. Und wisst ihr was? Wir sind nicht daran zerbrochen. Nicht weil das Internet damals harmloser war – das war es nicht. Sondern weil es Eltern gab, die mit uns geredet haben. Die uns erklärt haben, was da draussen existiert. Die uns beigebracht haben, kritisch zu denken, statt uns in eine digitale Gummizelle zu sperren.

Das ist der eigentliche Punkt, den die Politik nicht hören will: Kinderschutz ist eine Erziehungsaufgabe, keine Infrastrukturfrage. Ein Kind, dem niemand erklärt, warum bestimmte Inhalte problematisch sind, wird diese Inhalte finden – mit oder ohne Altersverifikation. Es wird den Ausweis der Eltern nehmen, ein VPN benutzen, das Gerät eines Freundes verwenden oder schlicht ein anderes Betriebssystem installieren. Jugendliche sind nicht dumm. Sie sind oft technisch versierter als die Politiker, die diese Gesetze schreiben.

Was diese Gesetze tatsächlich bewirken, ist etwas ganz anderes: Sie entmündigen Eltern. Sie signalisieren, dass der Staat die Erziehung übernimmt, weil er den Familien nicht zutraut, es selbst zu schaffen. Statt in Medienkompetenz zu investieren – in Schulen, in Elternbildung, in offene Gespräche über digitale Gefahren – wird eine technische Scheinlösung implementiert, die Milliarden kostet, die Freiheit aller einschränkt und am eigentlichen Problem komplett vorbeigeht.

Dabei existieren die Werkzeuge für Eltern längst: Apples Screen Time, Googles Family Link, Kinderschutzsoftware, Router-basierte Filter, betriebssystemeigene Benutzerkonten mit eingeschränkten Rechten. All das funktioniert – freiwillig, ohne staatliche Datenbank, ohne Ausweispflicht, ohne API, die eure Alterskategorie an jeden App-Entwickler weitergibt. Der Unterschied: Diese Werkzeuge geben Eltern die Kontrolle. Die neuen Gesetze geben sie dem Staat.

Und genau das ist der Kern der Sache. Es geht nicht darum, ob Kinder geschützt werden sollen – selbstverständlich sollen sie das. Es geht darum, wer sie schützt. Eltern, die ihre Kinder kennen, ihre Reife einschätzen können und individuelle Entscheidungen treffen? Oder ein Staatsapparat, der jeden Bürger in Alterskategorien einteilt, diese Daten über Schnittstellen weiterreicht und bei Nichtbefolgung mit sechsstelligen Bussen droht?

Die Antwort sollte in einer freien Gesellschaft nicht schwerfallen.

Was ihr tun könnt

Es ist Zeit, sich zu wehren – aktiv, laut und mit den Mitteln, die uns als Nutzer freier Software zur Verfügung stehen.

Installiert Linux. Wer noch Windows oder macOS nutzt, lebt bereits in einem Ökosystem, das Kontrolle über den Nutzer als Feature betrachtet. Linux-Distributionen wie Debian, Fedora oder Arch geben euch die Kontrolle über euer System zurück. Das war immer ihr grösster Vorteil – und er wird wichtiger als je zuvor.

Nutzt GrapheneOS. Auf dem Smartphone ist GrapheneOS die beste verfügbare Option für Nutzer, die sich nicht von Google oder Apple vorschreiben lassen wollen, was sie mit ihrem eigenen Gerät tun dürfen. Die klare Haltung des Projekts gegenüber der Altersverifikation ist nur ein weiterer Grund, umzusteigen.

Unterstützt die Open-Source-Community. Die Projekte, die sich gerade gegen diese Gesetze wehren, sind oft kleine Teams von Freiwilligen. Spendet. Beteiligt euch an Diskussionen. Meldet euch auf den Mailinglisten. Schreibt eurem Abgeordneten. Die Leute, die eure Freiheit verteidigen, brauchen eure Hilfe.

Klärt euer Umfeld auf. Viele Menschen verstehen nicht, was hier passiert. Sie hören „Jugendschutz" und nicken. Erklärt ihnen, warum eine Altersverifikation auf Betriebssystemebene keine Kinderschutz-Massnahme ist, sondern der Grundstein für eine digitale Ausweispflicht, die weit über den angeblichen Zweck hinausgehen wird.

Lehnt die eID-Wallet ab, solange es freiwillig ist. Nutzt alternative Wege. Jede Nutzungszahl, die die EU-Kommission als „Erfolg" verkaufen kann, beschleunigt den Weg zur Pflicht.

Schlussgedanke

Es geht hier nicht mehr um die Frage, ob wir Kinder im Internet schützen sollten – natürlich sollten wir das. Es geht darum, dass der „Schutz der Kinder" systematisch als Vorwand missbraucht wird, um eine Kontrollinfrastruktur aufzubauen, die jeden Bürger betrifft, die praktisch unwirksam gegen ihren angeblichen Zweck ist und die, einmal installiert, niemals wieder entfernt werden wird.

Freie Software ist nicht einfach ein Hobby oder eine technische Präferenz. Sie ist eine der letzten Verteidigungslinien gegen die schleichende Erosion digitaler Grundrechte. Wer heute Linux installiert, trifft keine technische Entscheidung – sondern eine politische.

Es geht langsam, aber sicher zu weit. Und wenn wir nicht jetzt aufstehen, wird es bald zu spät sein.

Quellen und weiterführende Links:

• heise online: Linux soll Ausweise prüfen – Wie die Community sich dagegen wehrt
• netzpolitik.org: Online-Alterskontrollen – Nur für Erwachsene
• netzpolitik.org: EU-Konzept – So sollen die Alterskontrollen im Netz ablaufen
• Linux-Magazin: GrapheneOS will Altersverifikation nicht unterstützen
• Tom's Hardware: California introduces age verification law for all operating systems
• EU-Kommission: Der EU-Ansatz zur Altersüberprüfung
• Kalifornien AB 1043 – Gesetzestext
• The Open Reader: Apple Rolls Out OS-Level Age Verification in the UK with iOS 26.4
• Bloomberg: Apple Rolls Out Age Verification for UK Users
• OS X Daily: iOS 26.4 Age Verification in UK Fails for Some
• Wikipedia: Online age verification in the United Kingdom
• EFF: UK Politicians Continue to Miss the Point
• ComplianceHub: Brazil's Radical Age Verification Law
• TechPolicy Press: Brazil Wants to Reshape The Internet for Kids
• Baker McKenzie: Brazil Regulates the Digital ECA
• Gov.uk: PM – No platform gets a free pass
• KJM: FAQs zum 6. Medienänderungsstaatsvertrag
• Medienanstalt MV: 6. MÄStV tritt in Kraft
• Berlin.de: Gesetz zum Sechsten Medienänderungsstaatsvertrag
• FSM: Wissen kompakt zum Jugendmedienschutz
• Bundestag WD 7: Bestimmungen über Altersverifikationssysteme im nationalen Recht (PDF)
• Servicestelle Jugendschutz: Neuer JMStV in Kraft

The post Altersverifikation auf Betriebssystemebene: Jugendschutz oder Überwachung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was VollaOS eigentlich ist

Volla bewirbt VollaOS gerne als eigenständiges, datenschutzfreundliches Betriebssystem. In Wirklichkeit ist es ein AOSP-Fork – also eine Ableitung des Android Open Source Project, genau wie hunderte andere Custom-ROMs auch. Volla entfernt Google-Dienste, baut eine eigene Oberfläche namens Springboard drauf und nennt das Ergebnis VollaOS.

Das ist legitim und durchaus sinnvoll für Nutzer, die Google loswerden wollen. Aber es ist wichtig zu verstehen, was das bedeutet und was nicht: Ihr bekommt Android ohne Google-Apps – aber keine von Grund auf neu entwickelte, sicherheitsgehärtete Plattform. Die Sicherheitsbasis ist identisch mit einem Standard-Android ohne Google-Dienste, nicht mehr und nicht weniger.

Manche Quellen bezeichnen VollaOS als LineageOS-Fork. Das ist nicht korrekt. Es basiert direkt auf AOSP. Dieser Unterschied ist relevant, weil LineageOS eigene Patches und eine aktive Community mitbringt – VollaOS hat das nicht.

Das Volla 22: jahrelanger Verkauf ohne Firmware-Updates

Bevor wir zum aktuellen Stand kommen, lohnt sich ein Blick zurück – denn er ist aufschlussreich.

Das Volla Phone 22 basiert auf dem Gigaset GS5, einem Gerät das im November 2021 für 299 Euro auf den Markt kam. Volla verkaufte es ab Januar 2023 für 452 Euro – also mit anderthalb Jahre alter Hardware und einem Aufpreis von über 50 Prozent. Wer schon damals genau hinschaute, hätte merken können, dass das Fundament wacklig ist.

Im September 2023 meldete Gigaset Insolvenz an. Das Unternehmen wurde zwar Anfang 2024 von VTech aus Hongkong übernommen, aber ausschliesslich das DECT-Telefon-Geschäft. Die Smartphone-Sparte wurde nicht weitergeführt.

Die Konsequenz für Volla 22 Besitzer: Firmware-Updates auf Hardware-Ebene gab es schon lange keine mehr. Community-Mitglieder bestätigten in Foren, dass es nur noch gelegentliche VollaOS App-Updates gab, aber keine echten Firmware-Patches für den MediaTek Helio G85. Für ein Gerät das explizit mit Sicherheit und Datenschutz vermarktet wurde, ist das ein schwer zu rechtfertigender Zustand. Ein Gerät ohne aktuelle Sicherheitspatches ist unabhängig von der installierten Software ein Sicherheitsrisiko – besonders wenn der Nutzer davon ausgeht, dass sein Datenschutz-Smartphone ihn schützt.

Das Quintus: Gleiche Problematik, neuere Verpackung

Das aktuelle Flaggschiff Volla Phone Quintus soll vieles besser machen. Und in mancher Hinsicht tut es das auch. Die Abhängigkeit von Gigaset ist vorbei – Volla gibt an, nun mit einem anonymen ODM-Hersteller zu arbeiten, der keine eigene Smartphone-Marke betreibt. Den Namen dieses Herstellers kommuniziert Volla nicht öffentlich.

Der verbaute Chip ist der MediaTek Dimensity 7050, der im Mai 2023 angekündigt wurde. Das Quintus erschien Anfang 2025, also kommt es bereits mit knapp zwei Jahre alter SoC-Technologie auf den Markt. Dazu kommt: Der Dimensity 7050 ist im Grunde ein umgelabelter Dimensity 1080, der wiederum auf dem Dimensity 920 aus dem Jahr 2021 aufbaut. Die eigentliche Chip-Architektur ist damit rund vier Jahre alt. Das ist ein Mittelklasse-Gerät, das im normalen Markt für etwa 250-300 Euro erhältlich wäre – Volla verkauft es für 719 Euro. Das ist gelinde ausgedrückt, schon fast frech.

Signature Spoofing: Der unbequeme Kompromiss

VollaOS integriert microG als optionale Alternative zu Google Play Services. Das ist grundsätzlich sinnvoll – microG reimplementiert die wichtigsten Google-APIs als Open-Source-Lösung und ermöglicht Push-Benachrichtigungen ohne Google-Konto. Standardmässig ist es deaktiviert, was die richtige Entscheidung ist.

Das Problem liegt tiefer: Damit microG funktioniert, benötigt es Signature Spoofing. Das ist eine Fähigkeit, die es Apps erlaubt, sich gegenüber dem System als eine andere App auszugeben. VollaOS aktiviert Signature Spoofing systemweit.

In der Android-Sicherheitsarchitektur ist die App-Sandbox ein zentrales Sicherheitsmerkmal. Jede App läuft isoliert, kann nicht auf Daten anderer Apps zugreifen, und Identitätsprüfungen über Signaturen sind der Mechanismus, der das durchsetzt. Signature Spoofing hebelt genau diesen Mechanismus aus. Eine böswillige App könnte damit vorgeben, eine andere – vertrauenswürdige – App zu sein.

Volla beschränkt Signature Spoofing zwar auf autorisierte Systemkomponenten, was das Risiko reduziert. Es bleibt aber eine messbare Schwächung des Android-Sicherheitsmodells, die bei einem auf Datenschutz und Sicherheit ausgerichteten Betriebssystem eigentlich nichts verloren hat.

WebView: Die unterschätzte Angriffsfläche

Einer der technisch relevantesten Unterschiede zwischen VollaOS und einem wirklich sicherheitsgehärteten System ist die WebView-Implementierung. WebView ist die Komponente, die in unzähligen Apps steckt – überall dort, wo eine App eine Webseite lädt, ohne einen vollständigen Browser zu öffnen. Banking-Apps, News-Reader, Social-Media-Clients: fast alle nutzen WebView.

VollaOS verwendet die Standard-Android-WebView, also ungepatchtes Chromium ohne zusätzliche Härtung. Das ist nicht schlimmer als ein normales Android-Gerät, aber es ist auch nicht besser.

GrapheneOS geht hier einen anderen Weg: Die eigene WebView-Implementierung namens Vanadium ist ein gehärteter Chromium-Fork. JIT-Compilation ist standardmässig deaktiviert – das ist die Fähigkeit des Browsers, zur Laufzeit nativen Code zu erzeugen und auszuführen, ein klassischer Angriffsvektor. Memory Tagging Extension (MTE) ist aktiv, was bestimmte Klassen von Speicher-Exploits zuverlässig verhindert. Vanadium reduziert ausserdem aktiv die Informationen, die Webseiten über das Gerät erhalten können.

Diese Unterschiede klingen technisch, haben aber praktische Relevanz: WebView-Schwachstellen sind ein häufig genutzter Angriffsvektor in gezielten Angriffen auf Mobilgeräte.

Was VollaOS bietet – und was nicht

Um fair zu sein: VollaOS bietet durchaus sinnvolle Privacy-Features. Der eingebaute Sicherheitsmodus erlaubt es, Apps den Internetzugang zu sperren, Hintergrundaktivitäten zu blockieren und bestimmte Domains zu filtern. Das ist praktisch und für technisch weniger versierte Nutzer zugänglich. Aurora Store und F-Droid sind vorinstalliert, microG ist integriert aber standardmässig deaktiviert. Das Springboard-Interface ist ein interessanter Ansatz für weniger ablenkungsreiches Smartphone-Nutzung.

Was VollaOS nicht hat:

Kein gehärteter Memory Allocator. GrapheneOS ersetzt Androids Standard-Allocator durch eine eigene Implementierung mit massiv verbesserter Resistenz gegen Heap-Exploits. VollaOS nutzt den AOSP-Standard.

Kein hardwarebasierter Exploit-Schutz. GrapheneOS nutzt auf Pixel-Geräten Memory Tagging Extension (MTE) systemweit – eine ARM-Hardwarefunktion, die bestimmte Klassen von Speicherkorrektionsangriffen zuverlässig erkennt und stoppt. Das funktioniert nur auf Geräten mit entsprechender Hardware-Unterstützung, also aktuellen Pixel-Geräten.

Keine Sandboxed Google Play. GrapheneOS erlaubt es, Google Play Services vollständig isoliert in einer normalen App-Sandbox zu betreiben – ohne Systemrechte, ohne Signature Spoofing. Wer Banking-Apps oder andere Google-abhängige Dienste benötigt, kann das nutzen, ohne das Sicherheitsmodell zu kompromittieren. VollaOS hat keine vergleichbare Lösung.

Keine Netzwerk- und Sensor-Permissions per App. GrapheneOS erlaubt es, einzelnen Apps den Internetzugang komplett zu sperren oder den Zugriff auf Sensoren zu blockieren. VollaOS hat einen App-Firewall-Modus, der ähnlich funktioniert, aber weniger granular ist.

Kein Auto-Reboot, kein PIN-Scrambling, kein Duress Pin. Kleine Details, die bei einem echten Sicherheitssystem dazugehören.

Die ehrliche Einordnung

VollaOS ist kein Sicherheitssystem. Es ist ein Privacy-System – und das ist ein wichtiger Unterschied.

Privacy bedeutet: weniger Daten fliessen zu Google und anderen Konzernen. Das erreicht VollaOS durchaus. Wer einfach Google aus seinem Smartphone-Leben entfernen möchte, bekommt mit VollaOS ein funktionierendes System mit akzeptabler App-Kompatibilität und einem einsteigerfreundlichen Interface.

Security bedeutet: das Gerät ist widerstandsfähig gegen Angriffe, Exploits und unbefugten Zugriff. Hier bietet VollaOS gegenüber einem Standard-AOSP keine nennenswerten Verbesserungen. Die Härtungsmassnahmen, die wirklich etwas ausmachen – gehärteter Allocator, Vanadium WebView, MTE, Sandboxed Play – fehlen vollständig.

Dazu kommt das grundsätzliche Hardware-Problem: Volla verkauft Geräte mit alter Hardware zu hohen Preisen, ohne langfristige Update-Garantien zu kommunizieren. Das Volla 22 hat gezeigt, wohin das führt. Das Quintus mag heute noch Updates bekommen – aber eine belastbare Zusage für vier oder fünf Jahre Sicherheitspatches gibt es nicht.

Wer besser bedient ist

Wer wirklich Wert auf Sicherheit legt – und dabei Privacy als selbstverständlich einschliesst – kommt an GrapheneOS auf einem aktuellen Pixel-Gerät nicht vorbei. Die Sicherheitsarchitektur ist nachweislich überlegen, die Update-Versorgung mit monatlichen Patches zuverlässig, und ein Pixel 8 ist für weniger Geld zu haben als ein Volla Quintus.

Wer nur Google-Tracking loswerden will und ein aktuelles Gerät mit guter Update-Versorgung hat, fährt mit Rethink DNS plus einigen App-Einschränkungen praktisch genauso gut wie mit VollaOS – und hat dabei bessere Sicherheitspatches. VollaOS hat seinen Vorteil hauptsächlich in der vollständigen Entfernung von Google Play Services auf Systemebene, was DNS-Blocking nicht leisten kann.

VollaOS ist ein interessantes Projekt für Nutzer, die mit einem einfachen Setup Google loswerden wollen und dafür bereit sind, einen deutschen Hersteller zu unterstützen. Als ernstzunehmende Sicherheitslösung kann es nicht überzeugen.

Gigaset Insolvenz

• https://www.fonial.de/blog/artikel/gigaset-ist-pleite-telefonhersteller-gigaset-meldet-insolvenz-an/
• https://borncity.com/blog/2024/01/25/gigaset-gerettet-neuer-eigentmer-gefunden/

Volla 22 / Gigaset GS5 Hardware-Basis

• https://www.linux-community.de/ausgaben/linuxuser/2023/04/volla-phone-22-und-x23/
• https://www.inside-digital.de/handys/gigaset-gs5

Volla 22 fehlende Firmware-Updates (Community)

• https://gnulinux.ch/zum-wochenende-das-volla-phone-22-im-test

Volla Quintus ODM-Hersteller (offizielles Volla-Statement)

• https://forums.ubports.com/topic/10338/volla-phone-quintus

MediaTek Dimensity 7050 Ankündigung Mai 2023

• https://i.mediatek.com/press_room/mediatek-dimensity-7050-to-power-next-gen-5g-smartphone-in-india

Signature Spoofing / Sicherheitskompromisse Custom ROMs

• https://gnulinux.ch/sicherheitskompromisse-freier-androidderivate
• https://privsec.dev/posts/android/choosing-your-android-based-operating-system/

GrapheneOS Features (Vanadium, hardened malloc, MTE)

• https://grapheneos.org/features

microG in VollaOS

• https://wiki.volla.online/index.php?title=MicroG_Guide_and_Setup

The post VollaOS: Datenschutz-Marketing vs. technische Realität appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dieser Artikel erklärt verständlich, wie diese Mechanismen funktionieren und warum sie so wichtig sind.

Die drei Standard-Datenströme unter Linux

Jedes Programm unter Linux besitzt automatisch drei sogenannte Standard-Streams:

Diese drei Kanäle bilden die Grundlage für die Kommunikation zwischen Programmen.

stdin (Standard Input)
Hierüber erhält ein Programm Daten. Meist kommt diese Eingabe von der Tastatur oder von einem anderen Programm.

stdout (Standard Output)
Hierüber gibt ein Programm seine normale Ausgabe aus. Standardmäßig wird diese im Terminal angezeigt.

stderr (Standard Error)
Fehlermeldungen werden über einen eigenen Kanal ausgegeben, getrennt von der normalen Ausgabe.

Der große Vorteil dieses Konzepts ist, dass sich diese Datenströme flexibel umleiten oder miteinander verbinden lassen.

Ein einfaches Beispiel

Ein klassischer Befehl:

echo "Hallo Welt"

Das Programm echo schreibt den Text auf stdout, und das Terminal zeigt ihn an:

Hallo Welt

Die Ausgabe wird also vom Programm erzeugt und über den Standard-Ausgabekanal an das Terminal geschickt.

Ausgabe in Dateien umleiten

Mit dem >-Operator lässt sich die Standardausgabe in eine Datei umleiten.

ls > dateiliste.txt

Die Dateiliste wird jetzt nicht mehr im Terminal angezeigt, sondern in die Datei dateiliste.txt geschrieben.

Fehler getrennt speichern

Da Fehlermeldungen über stderr laufen, können sie separat umgeleitet werden:

ls /existiert /nichtda 2> fehler.txt

Hier passiert folgendes:

• Die normale Ausgabe geht weiterhin ins Terminal.
• Die Fehlermeldungen landen in der Datei fehler.txt.

stdout und stderr zusammenführen

Oft möchte man sowohl normale Ausgabe als auch Fehler gemeinsam in einer Datei speichern. Dafür gibt es die bekannte Umleitung:

command > output.log 2>&1

Bedeutung:

1. > output.log leitet stdout in die Datei um
2. 2>&1 sorgt dafür, dass stderr an denselben Ort geschickt wird

Das Ergebnis: Beide Ausgaben landen im gleichen Logfile.

Ein wichtiger Punkt dabei ist die Reihenfolge.
Die korrekte Variante lautet:

command >file 2>&1

Wenn man die Reihenfolge vertauscht, funktioniert die Umleitung nicht wie erwartet.

Anhängen statt Überschreiben

Mit >> wird eine Datei nicht überschrieben, sondern erweitert:

command >> logfile 2>&1

Neue Ausgaben werden dann am Ende der Datei angehängt.

Diese Form sieht man häufig bei Logfiles.

Das schwarze Loch: /dev/null

Unter Linux existiert eine spezielle Gerätedatei namens:

/dev/null

Alles, was dorthin geschrieben wird, verschwindet einfach.

Man nennt sie deshalb oft scherzhaft ein schwarzes Loch für Daten.

Ausgabe unterdrücken

command > /dev/null

Die normale Ausgabe verschwindet, Fehlermeldungen bleiben sichtbar.

Alles unterdrücken

command > /dev/null 2>&1

Jetzt werden sowohl stdout als auch stderr verworfen.

Diese Technik wird häufig in Scripts oder Cronjobs eingesetzt, wenn man bewusst keine Ausgabe erzeugen möchte.

Programme miteinander verbinden (Pipes)

Ein besonders mächtiges Unix-Konzept sind Pipelines.

Dabei wird die Ausgabe eines Programms direkt zur Eingabe eines anderen Programms weitergeleitet.

ps aux | grep python

Ablauf:

1. ps aux erzeugt eine Prozessliste über stdout
2. Die Pipe | leitet diese Ausgabe weiter
3. grep bekommt die Daten über stdin und filtert sie

So lassen sich komplexe Aufgaben aus vielen kleinen Werkzeugen zusammensetzen.

Moderne Anwendungen: systemd und Docker

Viele moderne Dienste nutzen das stdout/stderr-Prinzip direkt für Logging.

systemd

Services schreiben ihre Logs einfach auf stdout oder stderr.
systemd speichert diese automatisch im Journal.

Logs anzeigen:

journalctl -u servicename

Live-Logs:

journalctl -u servicename -f

Docker

Auch Container folgen diesem Prinzip. Anwendungen schreiben Logs einfach auf stdout.

Abrufen der Logs:

docker logs containername

Live verfolgen:

docker logs -f containername

Deshalb besitzen viele Container gar keine eigenen Logfiles mehr.

Fazit

Das stdout/stderr-Konzept gehört zu den elegantesten Ideen im Unix-Design. Es erlaubt:

• flexible Umleitung von Ausgaben
• getrennte Behandlung von Fehlern
• einfache Verknüpfung von Programmen
• sauberes Logging in modernen Systemen

Wer regelmäßig mit Linux arbeitet, wird diese Mechanismen ständig verwenden – oft sogar ohne es bewusst zu merken.

Gerade in Shell-Scripts und bei der Serveradministration sind sie unverzichtbar.

Wenn man das Prinzip einmal verstanden hat, öffnet sich eine der größten Stärken von Unix-Systemen: kleine Werkzeuge lassen sich beliebig kombinieren.

The post stdout, stderr und /dev/null – Die wichtigsten Linux-Datenströme verständlich erklärt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Doch es gibt ein drittes Puzzleteil, das dieses Bild vervollständigt und die Bedrohung auf eine neue Ebene hebt: die Firma Palantir Technologies und ihr Zusammenspiel mit dem US-Biometriesystem HART. Während CLOUD Act und FISA Section 702 den rechtlichen Rahmen für Datenabschöpfung liefern, stellt Palantir die Technologie bereit, um diese Daten zu verknüpfen, zu analysieren und in verwertbare Informationen umzuwandeln. Und das Beunruhigendste daran: Diese Technologie hält gerade Einzug bei der deutschen Polizei.

Palantir: Vom CIA-Startup zum globalen Überwachungskonzern

Die Ursprünge: Silicon Valley trifft Geheimdienst

Die Geschichte von Palantir Technologies beginnt dort, wo man es erwarten würde: an der Schnittstelle zwischen Silicon Valley und dem US-Geheimdienstapparat. Im Jahr 2003 gründete der libertäre Tech-Milliardär Peter Thiel – bereits bekannt als Mitgründer von PayPal – zusammen mit mehreren Mitgründern das Unternehmen in Palo Alto. Die entscheidende Anschubfinanzierung kam von In-Q-Tel, dem Risikokapitalarm der CIA. Dieser Umstand allein sollte jedem in Europa die Alarmglocken schrillen lassen.

Der Name „Palantir" ist dabei kein Zufall. In J.R.R. Tolkiens „Herr der Ringe" sind die Palantíri magische Sehsteine, die den Blick an weit entfernte Orte ermöglichen. Mächtig, verführerisch – aber auch gefährlich, denn wer hineinblickt, riskiert, selbst beobachtet zu werden. Die Symbolik hätte kaum treffender sein können.

Das Unternehmen vertritt die Philosophie der „Augmented Intelligence" – der erweiterten Intelligenz. Die Grundidee: Künstliche Intelligenz allein reicht nicht aus, um komplexe Bedrohungen zu erkennen. Stattdessen braucht man menschliche Analysten, die mit Hilfe von Software riesige Datenmengen aus unterschiedlichsten Quellen zusammenführen und auswerten können. Was zunächst für die Terrorismusbekämpfung entwickelt wurde, ist längst zu einem universellen Überwachungsinstrument geworden.

Zwei Produkte, ein Ziel: Totale Datenverknüpfung

Palantir betreibt zwei Hauptprodukte, die ihr kennen solltet:

Gotham ist das Flaggschiff für Geheimdienste, Militär und Strafverfolgung. Es wurde entwickelt, um Verbindungen zwischen Personen, Orten, Objekten und Ereignissen zu erkennen und zu visualisieren. Gotham kann strukturierte Daten wie Kontaktlisten, Funkzellenabfragen und Reisehistorien mit unstrukturierten Daten wie Fotos, Videoaufnahmen und Textdokumenten verknüpfen. Zu den Kunden gehören die CIA, die NSA, das FBI, das US-Verteidigungsministerium, ICE (Immigration and Customs Enforcement) und – wie ihr gleich erfahren werdet – auch deutsche Polizeibehörden.

Foundry richtet sich an Unternehmen und zivile Behörden und hilft dabei, massive Datensätze zu vereinheitlichen und zu visualisieren. Während der COVID-19-Pandemie bot Palantir Regierungen weltweit Foundry kostenlos an – ein Angebot, das Großbritannien und Griechenland annahmen. Hessen hatte ebenfalls Interesse bekundet, entschied sich letztlich aber dagegen. Die Strategie dahinter ist offensichtlich: Kostenloser Einstieg, langfristige Abhängigkeit.

Palantir und der US-Überwachungsapparat: Eine symbiotische Beziehung

Palantirs Verwicklung in den US-Überwachungsapparat ist nicht bloß historisch. Sie ist aktuell und tiefgreifend. Seit 2013 liefert Palantir der Einwanderungsbehörde ICE Systeme wie FALCON und das Investigative Case Management (ICM). Diese Werkzeuge wurden nachweislich bei Arbeitsplatzrazzien, groß angelegten Durchsetzungsoperationen und Ermittlungen gegen Asylsuchende eingesetzt. Im Jahr 2025 ging Palantir noch einen Schritt weiter: Für 30 Millionen Dollar entwickelt das Unternehmen „ImmigrationOS" – eine KI-gestützte Plattform, die Einwanderer identifizieren, verfolgen und für Abschiebungen markieren soll. Der Prototyp sollte bis September 2025 stehen.

Palantirs Systeme ziehen dabei Daten aus einer Vielzahl von Regierungsdatenbanken: Passregister, Sozialversicherungsdaten, IRS-Steuerdaten, Kennzeichenerfassungssysteme und – das ist der entscheidende Punkt – biometrische Datenbanken. Hier kommt HART ins Spiel.

Und hier wird auch die Verbindung zu unseren vorangegangenen Artikeln deutlich: Palantir unterliegt als US-Unternehmen sowohl dem CLOUD Act als auch FISA Section 702. Wie wir in unserem FISA-Artikel beschrieben haben, wurde Section 702 im April 2024 durch den RISAA (Reforming Intelligence and Securing America Act) erheblich ausgeweitet. Die neue Definition von „Electronic Communications Service Providers" ist so breit gefasst, dass praktisch jedes Unternehmen mit Zugang zu Kommunikationsinfrastruktur zur Kooperation mit US-Geheimdiensten gezwungen werden kann. Die brisante Frage, welchen konkreten Verpflichtungen Palantir nach dem verschärften FISA unterliegt und was das für Daten in deutschen Polizeisystemen bedeutet, wurde bei einer Anhörung im Bundestag-Innenausschuss im April 2024 von keinem einzigen Abgeordneten gestellt.

HART: Die größte biometrische Datenbank der Welt

Was ist HART?

Während Palantir die Analysetechnologie liefert, wird auf der anderen Seite des Atlantiks eine Datenbank aufgebaut, die das Rückgrat der US-Überwachungsinfrastruktur bilden soll: HART – Homeland Advanced Recognition Technology. Dieses System wird vom US-Department of Homeland Security (DHS) entwickelt und soll die veraltete IDENT-Datenbank ablösen, die bereits heute Informationen über mehr als 300 Millionen Personen enthält und täglich rund 350.000 biometrische Transaktionen verarbeitet.

HART ist nicht einfach nur ein Upgrade. Es ist ein Quantensprung in der Überwachungskapazität. Das System wird mindestens sieben verschiedene biometrische Identifikatoren unterstützen: Fingerabdrücke, Gesichtserkennung, Iris-Scans, DNA-Profile, Stimmerkennung, Narben und Tätowierungen – sowie eine offene Kategorie für „andere Modalitäten". In jüngsten Dokumenten hat das DHS diese Definition sogar noch erweitert: Tipprhythmus, Herzsignatur und Gefäßmuster stehen ebenfalls zur Diskussion.

Umfang und Kosten: Zahlen, die schwindelig machen

HART ist ein Projekt der Superlative. Das geplante Budget beträgt 6,158 Milliarden Dollar. Das System soll Daten für mindestens 75 Jahre speichern. Es wird voraussichtlich 6,7 Millionen Iris-Scans und 1,1 Milliarden Gesichtsbilder initial aufnehmen. Und es wird nicht nur biometrische Daten enthalten, sondern auch biografische Informationen wie Namen, Geburtsdaten, Herkunftsländer, Regierungs-IDs – sowie höchst subjektive Daten wie „Beziehungsmuster" und „Begegnungsdaten" aus Polizeikontakten.

HART wird auf der Amazon Web Services (AWS) GovCloud gehostet – derselben Infrastruktur, auf der auch andere DHS-Systeme laufen. Mehr als 41 Menschenrechtsorganisationen, darunter Access Now, die Electronic Privacy Information Center (EPIC) und Mijente, haben AWS in einem öffentlichen Brief aufgefordert, das Hosting einzustellen. Ihre Warnung: AWS ermöglicht damit die Schaffung einer invasiven Biometriedatenbank, die Überwachung und Abschiebungen auf ein neues Niveau heben wird.

Wer landet in HART – und wer hat Zugriff?

HART erfasst nicht nur verdächtige Personen oder Einwanderer. In der Datenbank landen auch US-Bürger und Personen, die niemals eine Straftat begangen haben. Jede Person, die jemals einen Kontakt mit dem DHS hatte – sei es bei einer Grenzkontrolle, einem Visumantrag, einer Einbürgerung oder auch nur als Zeuge – kann in HART erfasst werden. Jeder solcher „Encounter" wird protokolliert und kann in einem Feedbackloop zu weiteren Überprüfungen führen.

Der Zugriff auf HART ist dabei keineswegs auf das DHS beschränkt. Das System wird mit föderalen Behörden wie dem FBI geteilt, mit Bundesstaats- und Kommunalpolizei und – hier wird es für euch als Europäer besonders relevant – mit ausländischen Regierungen. Europol hat operative Abkommen mit den USA im Bereich „ausländische Kämpfer", und Daten fließen über das FBI als Vermittler auch an europäische Behörden. Im Bereich der Terrorismusbekämpfung verschwimmen die Grenzen zwischen nationalen und internationalen Datenbeständen zunehmend.

HART und Palantir: Das perfekte Zusammenspiel

Palantir ist zwar nicht direkt an der Entwicklung von HART beteiligt, aber das Unternehmen liefert die Analyseplattformen, die auf genau diese Daten zugreifen. Palantirs ICM (Investigative Case Management) und FALCON können Informationen aus IDENT/HART mit Daten aus Dutzenden anderen Quellen verknüpfen – Steuerdaten, Kennzeichenerfassung, Soziale Medien, Fluggastdaten. Die neue ImmigrationOS-Plattform wird diese Integration noch vertiefen.

Die Kombination ist bestechend einfach: HART sammelt und speichert die biometrischen und biografischen Daten von Hunderten Millionen Menschen. Palantir analysiert diese Daten, erkennt Muster, erstellt Profile und markiert Zielpersonen. FISA Section 702 und der CLOUD Act liefern die rechtliche Grundlage für den Zugriff – auch auf Daten, die bei europäischen Tochtergesellschaften von US-Firmen liegen. Was in unseren vorangegangenen Artikeln als theoretische Bedrohung beschrieben wurde, manifestiert sich hier in konkreter Technologie.

Und das DHS gibt offen zu, dass es die Genauigkeit und Qualität der Daten in HART nicht gewährleisten kann, da viele Daten von Drittparteien stammen – darunter auch kommerzielle Anbieter wie LexisNexis und Clearview AI. Trotzdem sollen diese fehlerhaften Daten 75 Jahre lang aufbewahrt werden. Die Redress-Mechanismen – also die Möglichkeiten für Betroffene, ihre Daten einzusehen, zu korrigieren oder löschen zu lassen – sind praktisch nicht existent.

Palantir in Europa: Die stille Expansion

Europol: Der Einstieg durch die Hintertür

Palantirs Einzug in Europa begann nicht in Deutschland, sondern bei Europol in Den Haag. Nach den Terroranschlägen in Paris im November 2015 richtete Europol die Taskforce „Fraternité" ein. Über den niederländischen Arm der Unternehmensberatung Capgemini – und nicht direkt über Palantir – wurde Gotham beschafft und ab 2016 getestet. Seit Mitte 2017 setzte Europol die Software für die operative Analyse aller terrorismusbezogenen Daten ein.

Die verschlungene Beschaffung über Capgemini als Zwischenhändler wirft bis heute Fragen auf. Der Rahmenvertrag wurde bereits 2012 geschlossen – vier Jahre vor dem ersten dokumentierten Einsatz. Die EU-Kommission erläuterte nie, wofür die Software in dieser Zwischenzeit genutzt wurde. Die Ausgabenobergrenze lag bei 7,5 Millionen Euro; tatsächlich ausgegeben wurden rund vier Millionen.

Besonders brisant: Europol teilte die Analyseergebnisse nicht nur mit EU-Mitgliedstaaten, sondern auch mit Drittstaaten – darunter den USA. Im Bereich „ausländische Kämpfer" flossen Daten über das FBI direkt an US-Behörden. Dies geschah parallel zu einer Zeit, in der der EuGH das Privacy-Shield-Abkommen kippte und feststellte, dass die USA kein angemessenes Datenschutzniveau bieten.

Laut dem Vize-Direktor von Europol wurde das Palantir-System schließlich 2021 durch eine Eigenentwicklung ersetzt – offiziell wegen mangelnder Kompatibilität mit anderen Europol-Systemen. Europol gab auf Journalistenanfragen allerdings nur zwei von 69 relevanten Dokumenten frei. Aus einem davon geht hervor, dass Europol sogar rechtliche Schritte gegen Palantir wegen Leistungsmängeln erwogen, diese jedoch aus Kostengründen verworfen hatte.

Palantir bei der deutschen Polizei: Von Hessendata zu VeRA

Hessen: Der Pionier (seit 2017)

Hessen war das erste Bundesland, das Palantirs Gotham unter dem Namen „Hessendata" einführte. 2017 beschaffte das Innenministerium die Software – der Preis wurde aus „Gründen des Sicherheitsinteresses" nicht veröffentlicht. Offiziell ging es um Terrorismusbekämpfung und organisierte Kriminalität. In der Praxis sieht es anders aus: In Hessen greifen Polizeibehörden jährlich rund 15.000 Mal auf das System zu. Nur in etwa einem von zwanzig Fällen steht dies im Zusammenhang mit schweren Gefahren. Die Software wurde unter anderem bei der Aufklärung von Geldautomatensprengungen und – deutlich weniger dramatisch – bei Fahrraddiebstählen eingesetzt.

Hessens Innenminister Roman Poseck (CDU) verteidigt den Einsatz: Ein Verzicht würde eine „spürbare Sicherheitslücke" hinterlassen. Datenschützer sehen das anders: Hessendata verknüpft polizeiliche Datenbanken mit Social-Media-Daten. Dass dabei keine Daten in die USA übertragen werden, ist zwar vertraglich zugesichert – aber nur schwer nachprüfbar.

Nordrhein-Westfalen: DAR

Auch Nordrhein-Westfalen nutzt eine angepasste Version von Palantir unter der Bezeichnung DAR (Datenbankübergreifende Analyse und Recherche). Mit Hilfe der Software konnten Ermittler das bisher größte Missbrauchsnetzwerk in Deutschland aufdecken, das 2021 in Bergisch Gladbach zerschlagen wurde. Dieser Erfolg wird regelmäßig als Argument für die Software angeführt.

Bayern: VeRA und der Rahmenvertrag (seit 2024)

Im Spätsommer 2024 startete Bayern den Einsatz der Palantir-Software VeRA (Verfahrensübergreifende Recherche- und Analyseplattform). Bayern hat dabei eine Schlüsselrolle: Das Bayerische Landeskriminalamt schloss nach einem EU-weiten Vergabeverfahren einen Rahmenvertrag mit Palantir, der es allen Polizeibehörden des Bundes und der Länder ermöglicht, sich ohne eigenes Vergabeverfahren anzuschließen. Der Preis: 5,4 Millionen Euro Anschaffungskosten plus 500.000 Euro jährliche Betriebskosten.

VeRA führt verschiedene Datenbanken zusammen, die Informationen über mehr als 30 Millionen Menschen enthalten, und durchsucht sie präventiv. Der bayerische Datenschutzbeauftragte bewertete das Vorgehen als unverhältnismäßig, da auch Daten unbescholtener Personen einbezogen werden. Im LKA Bayern arbeiten mittlerweile rund 200 geschulte Analysten mit der Software.

Baden-Württemberg: Der jüngste Beitritt (2025)

Im November 2025 stimmte der Landtag Baden-Württemberg trotz erheblicher Widerstände – auch aus den Reihen des grünen Koalitionspartners – für die Einführung von Palantir. Eine Petition sammelte 13.000 Unterschriften dagegen. Eine Urabstimmungsinitiative bei den Grünen wurde eingereicht. Landespolizeipräsidentin Stefanie Hinz erklärte vor dem Landtag, Palantir sei der „technologische Marktführer" und es gebe keine vergleichbaren, zeitnah verfügbaren Alternativen.

Langfristig will Baden-Württemberg gemeinsam mit Partnern wie Airbus Defence and Space und Schwarz Digits (der IT-Sparte der Schwarz Gruppe) eine eigene, souveräne Software entwickeln. Bis dahin nutzt man Palantir. Ein Versprechen, das den Lock-in-Effekt praktisch garantiert: Ist das System erst einmal implementiert und die Polizei darauf geschult, wird ein Wechsel extrem teuer und aufwendig.

Bundesebene: Dobrindt prüft, die SPD bremst

Seit Sommer 2025 prüft das Bundesinnenministerium unter Alexander Dobrindt (CSU) den bundesweiten Einsatz. Dobrindt erklärte öffentlich, er habe „kein Störgefühl gegenüber einer Software, nur weil sie vom Anbieter Palantir kommt." Bundesjustizministerin Hubig (SPD) äußerte sich dagegen skeptisch und betonte, es könnten nur rechtsstaatlich konforme Mittel eingesetzt werden.

Im Koalitionsvertrag der schwarz-roten Bundesregierung ist zwar von „automatisierter Datenrecherche und -analyse" mittels KI die Rede. Bedingung sei jedoch die Wahrung verfassungsrechtlicher Vorgaben und der „digitalen Souveränität". Ob Palantir diese Bedingungen erfüllt, ist mehr als fraglich.

Weitere europäische Kunden

Deutschland steht mit seinem Palantir-Einsatz nicht allein. Frankreichs Inlandsgeheimdienst DGSI setzt die Software ein. Großbritannien nutzte Palantir-Produkte im Gesundheitswesen. Polen setzt sie auf dem Arbeitsmarkt ein. Und die NATO hat einen Vertrag mit dem US-Unternehmen geschlossen. Die stille Expansion schreitet voran.

Das Bundesverfassungsgericht zieht Grenzen – und wird ignoriert

Am 16. Februar 2023 fällte das Bundesverfassungsgericht ein wegweisendes Urteil. Die Verfassungsbeschwerden, eingereicht von der Gesellschaft für Freiheitsrechte (GFF), richteten sich gegen die gesetzlichen Grundlagen für den Einsatz von Palantir-Software in Hessen und Hamburg. Das Gericht urteilte klar: Die bestehenden Regelungen sind verfassungswidrig. Sie verstoßen gegen das Recht auf informationelle Selbstbestimmung (Art. 2 Abs. 1 i.V.m. Art. 1 Abs. 1 GG).

Die zentrale Aussage des Gerichts: „Die Befugnisse lassen die automatisierte Verarbeitung unbegrenzter Datenbestände mittels rechtlich unbegrenzter Methoden zu." Data Mining, KI-Einsatz und Predictive Policing werden weder ausgeschlossen noch rechtlich eingeschränkt. Das Gericht forderte mindestens eine „konkretisierte Gefahr" als Eingriffsanlass.

Das Urteil hätte ein Wendepunkt sein können. Stattdessen geschah Folgendes: Die betroffenen Bundesländer passten ihre Polizeigesetze formal an – und machten im Wesentlichen weiter wie bisher. Hessen überarbeitete Hessendata, schwärzt nun Opfernamen und passte einige Features an. Bayern erließ ein neues Polizeiaufgabengesetz, das den Einsatz „konform" zum Urteil ermöglichen soll. Im Juli 2025 reichte die GFF jedoch eine erneute Verfassungsbeschwerde ein – diesmal gegen Bayerns VeRA-Einsatz, da die neuen Regelungen weiterhin unverhältnismäßig seien und keine wirksamen Kontroll- und Schutzmechanismen vorsehen.

Warum Palantir bei der deutschen Polizei ein Souveränitätsproblem ist

Die FISA-Frage, die niemand stellt

Hier kommen unsere früheren Artikel direkt zum Tragen. Palantir Technologies ist ein US-Unternehmen mit Hauptsitz in Denver, Colorado. Es unterliegt uneingeschränkt US-amerikanischem Recht – einschließlich dem CLOUD Act und FISA Section 702.

Wie wir in unserem CLOUD-Act-Artikel ausführlich dargelegt haben, können US-Behörden von US-Unternehmen die Herausgabe von Daten verlangen – unabhängig davon, wo diese Daten gespeichert sind. Und wie unser FISA-Artikel zeigt, verpflichtet Section 702 US-Unternehmen zur Kooperation mit der NSA bei der Überwachung von Nicht-US-Bürgern.

Die entscheidende, unbeantwortete Frage lautet: Welchen konkreten Verpflichtungen unterliegt Palantir nach dem verschärften FISA? Kann die NSA Palantir anweisen, über Gotham/VeRA gewonnene Erkenntnisse aus deutschen Polizeidatenbanken herauszugeben? Palantir beteuert, selbst keine Daten zu sammeln, zu verkaufen oder für eigene Zwecke zu verarbeiten. Doch das ist nicht die relevante Frage. Die relevante Frage ist, ob Palantir auf Anweisung von US-Behörden Zugriff auf Daten gewähren muss, die über seine Software verarbeitet werden.

Innenminister Dobrindt verweist auf ein Gutachten des Fraunhofer-Instituts, das den Vorwurf von Datenabflüssen widerlege. Doch dieses Gutachten prüfte den Quellcode zu einem bestimmten Zeitpunkt. Ein Software-Update kann die Situation jederzeit ändern. Und die rechtliche Verpflichtung eines US-Unternehmens zur Kooperation mit US-Geheimdiensten lässt sich nicht durch ein technisches Gutachten widerlegen – sie ergibt sich aus dem Gesetz.

Die Starlink-Lehre

Die Kritiker verweisen auf ein anschauliches Beispiel: den Starlink-Einsatz in der Ukraine. Dort hat sich gezeigt, wie ein einzelnes US-Tech-Unternehmen durch politisch motivierte Entscheidungen massiven Einfluss auf die Sicherheitslage eines ganzen Landes nehmen kann. Die Vorstellung, dass die innere Sicherheit Deutschlands von den Geschäftsentscheidungen eines Unternehmens in Colorado abhängt, dessen Gründer Peter Thiel einer der größten Unterstützer von Donald Trump ist, sollte jeden demokratisch gesinnten Bürger beunruhigen.

Blackbox-Algorithmen und demokratische Kontrolle

Ein weiteres fundamentales Problem: Gotham ist proprietäre Software. Der Quellcode ist ein Geschäftsgeheimnis. Entscheidungen, die auf den Analysen von Palantir beruhen, sind für Betroffene nicht nachvollziehbar. Wie soll man sich gegen einen Verdacht wehren, dessen Zustandekommen man nicht versteht? Wie sollen Gerichte die Rechtmäßigkeit einer Maßnahme prüfen, wenn die entscheidenden Algorithmen ein Geschäftsgeheimnis sind?

Constanze Kurz, Sprecherin des Chaos Computer Clubs, bringt es auf den Punkt: Die zusammengeführten Daten landen in einer „absichtlich undurchschaubaren Software des US-Konzerns Palantir, von der sich die Polizei auf Jahre abhängig macht." Das seien klare Ausschlusskriterien für Daten aus dem Innenleben der Polizei.

Wer landet im System?

Die Palantir-Software erfasst nicht nur Tatverdächtige. Wer als Zeuge bei einem Autounfall aussagt, Anzeige gegen jemanden erstattet oder einfach nur am selben Bahnhof in eine Kontrolle gerät wie eine gesuchte Person, kann im System landen. Auch Opfer von Straftaten, Kontaktpersonen, Auskunftspersonen – sie alle sind in den polizeilichen Datenbanken gespeichert, die Palantir durchforstet.

Die GFF warnte ausdrücklich: „Schon wer Anzeige erstattet, Opfer einer Straftat wird oder einfach nur zur falschen Zeit am falschen Ort ist, kann durch die Software ins Visier der Polizei geraten." Besonders alarmierend ist dies im Kontext des Erstarkens rechtsextremer Kräfte. Gelangt die AfD in eine Landesregierung, könnte sie theoretisch auf Palantir-Systeme zugreifen und diese für ihre Zwecke nutzen – etwa nach dem Vorbild der Trump-Administration zur gezielten Erfassung und Abschiebung von Menschen.

Die Verbindung: Vom CLOUD Act über FISA Section 702 zu HART und Palantir

Für diejenigen unter euch, die unsere Artikelserie verfolgt haben, wird nun das Gesamtbild deutlich. Es handelt sich nicht um isolierte Bedrohungen, sondern um ein ineinandergreifendes System:

Der CLOUD Act (Artikel 1 dieser Serie) schafft die rechtliche Grundlage dafür, dass US-Behörden von US-Unternehmen wie Palantir die Herausgabe von Daten verlangen können – unabhängig davon, ob diese auf Servern in Deutschland, den Niederlanden oder anderswo in der EU liegen.

FISA Section 702 (Artikel 2 dieser Serie) ermöglicht es der NSA, die Kommunikation von Nicht-US-Bürgern anlasslos und massenhaft zu überwachen – über US-Anbieter wie die, deren Infrastruktur Palantir nutzt. Seit der RISAA-Erweiterung 2024 ist der Kreis der zur Kooperation verpflichteten Unternehmen erheblich gewachsen.

HART sammelt biometrische und biografische Daten von Hunderten Millionen Menschen in einer zentralisierten Datenbank, die mit US-Behörden, lokaler Polizei und ausländischen Regierungen geteilt wird.

Palantir liefert die Technologie, die all diese Datenströme zusammenführt, analysiert und in verwertbare Informationen umwandelt. Und genau diese Technologie wird nun bei der deutschen Polizei eingeführt.

Die Frage, die sich jeder stellen sollte: Wenn ein US-Unternehmen, das von der CIA mitfinanziert wurde, das mit NSA, FBI und ICE zusammenarbeitet, das dem CLOUD Act und FISA Section 702 unterliegt – wenn dieses Unternehmen Zugriff auf die zusammengeführten Datenbanken der deutschen Polizei erhält, die Informationen über mehr als 30 Millionen Menschen enthalten: Wie sicher sind diese Daten dann wirklich vor dem Zugriff der US-Geheimdienste?

Was ihr tun könnt

Die Debatte um Palantir ist noch nicht entschieden. Es gibt Handlungsmöglichkeiten:

Informiert euch und andere. Das größte Problem ist die mangelnde öffentliche Aufmerksamkeit. Die meisten Menschen wissen nicht einmal, dass ihre Daten in Polizeidatenbanken landen können, ohne dass sie jemals verdächtigt wurden – und dass diese Daten nun potenziell mit US-Überwachungstechnologie analysiert werden.

Unterstützt Organisationen, die sich für digitale Grundrechte einsetzen. Die Gesellschaft für Freiheitsrechte (GFF) führt die juristischen Kämpfe gegen den Palantir-Einsatz. Der Chaos Computer Club liefert die technische Expertise. Campact organisiert öffentlichen Druck. Diese Arbeit braucht Unterstützung.

Fordert europäische Alternativen. Die Innenministerkonferenz hat im Juni 2025 beschlossen, eine europäische Alternative zu Palantir suchen zu wollen. Dieser Beschluss muss mit Leben gefüllt werden. Quelloffene, transparente, demokratisch kontrollierbare Software – entwickelt in Europa, für europäische Rechtsstandards.

Setzt euch politisch ein. Schreibt euren Landtags- und Bundestagsabgeordneten. Fragt sie konkret: Welchen FISA-Verpflichtungen unterliegt Palantir? Wie wird garantiert, dass keine Daten an US-Behörden fließen? Warum gibt es keine Transparenz über den Quellcode? Warum wird keine europäische Open-Source-Alternative priorisiert?

Achtet auf eure eigene Datenspur. In unseren vorangegangenen Artikeln haben wir bereits empfohlen, auf europäische Alternativen zu setzen: Nextcloud statt Google Drive, Tuta oder Proton Mail statt Gmail, Signal oder Element/Matrix statt WhatsApp. Jede Entscheidung für einen europäischen Dienst ist eine Entscheidung gegen die Abhängigkeit von US-Technologie.

Fazit: Die Sehsteine von Palantir gehören nicht in europäische Hände

In Tolkiens Welt galt eine simple Wahrheit: Wer die Palantíri leichtfertig nutzt, riskiert, von einer dunkleren Macht beobachtet und manipuliert zu werden. Die Parallelen zur realen Welt sind frappierend.

Palantirs Gotham mag ein leistungsfähiges Werkzeug für die Polizeiarbeit sein. Die Erfolge bei der Aufklärung schwerer Straftaten sind real. Doch der Preis, den wir dafür zahlen, ist zu hoch: die Untergrabung des Grundsatzes der Zweckbindung, die Schaffung einer undurchsichtigen Überwachungsinfrastruktur, die Abhängigkeit von einem US-Unternehmen mit engen Geheimdienstverbindungen, und die faktische Aushöhlung der digitalen Souveränität.

Die Lösung ist nicht, auf moderne Analysetechnologie zu verzichten. Die Lösung ist, europäische, quelloffene, demokratisch kontrollierbare Alternativen zu entwickeln. Bis dahin gilt: Jede Polizeidatenbank, die über Palantir-Software analysiert wird, ist potenziell eine Datenbank, auf die US-Geheimdienste Zugriff haben könnten. Nicht weil Palantir böswillig wäre – sondern weil US-Recht dies ermöglicht und das Unternehmen gar keine Wahl hätte.

Unsere drei Artikel zeigen ein konsistentes Bild: Der CLOUD Act, FISA Section 702, HART und Palantir sind keine voneinander isolierten Phänomene. Sie sind die Zahnräder einer Maschinerie, die darauf ausgelegt ist, globale Datenströme unter US-amerikanische Kontrolle zu bringen. Und Europa öffnet dieser Maschinerie gerade bereitwillig die Tür.

Quellen und weiterführende Informationen

1. Electronic Frontier Foundation (EFF): „HART: Homeland Security's Massive New Database Will Include Face Recognition, DNA, and Peoples' 'Non-Obvious Relationships'" – https://www.eff.org/deeplinks/2018/06/hart-homeland-securitys-massive-new-database-will-include-face-recognition-dna-and
2. Immigrant Defense Project / Just Futures Law / Mijente: „HART Attack: How DHS's Massive Biometrics Database Will Supercharge Surveillance and Threaten Rights" – https://surveillanceresistancelab.org/featured-work/hart-attack-how-dhss-massive-biometrics-database-will-supercharge-surveillance-and-threaten-rights/
3. FedScoop: „Homeland Security centralizes control over the government's largest biometrics database" (August 2025) – https://fedscoop.com/homeland-security-centralizes-control-over-the-governments-largest-biometrics-database/
4. American Immigration Council: „ICE to Use ImmigrationOS by Palantir" (August 2025) – https://www.americanimmigrationcouncil.org/blog/ice-immigrationos-palantir-ai-track-immigrants/
5. Bundesverfassungsgericht: Urteil vom 16. Februar 2023 – 1 BvR 1547/19 – https://www.bundesverfassungsgericht.de/SharedDocs/Entscheidungen/DE/2023/02/rs20230216_1bvr154719.html
6. Gesellschaft für Freiheitsrechte (GFF): Verfassungsbeschwerde gegen Palantir in Bayern (Juli 2025) – https://freiheitsrechte.org/themen/freiheit-im-digitalen/palantir-bayern
7. Handelsblatt: „Palantir erhält Rückendeckung aus der Bundesregierung" (August 2025) – https://www.handelsblatt.com/politik/deutschland/polizei-software-palantir-erhaelt-rueckendeckung-aus-der-bundesregierung/100150618.html
8. Campact: „Nein zum Palantir-Deal" – https://www.campact.de/datenschutz/peter-thiel-palantir-polizei-software-stoppen-petition/
9. Ingenieur.de: „Palantir in Deutschland: Polizei schwärmt, Datenschützer warnen" (November 2025) – https://www.ingenieur.de/technik/fachbereiche/ittk/polizei-schwaermt-datenschuetzer-warnen-palantir-im-deutschen-praxistest/
10. Friedrich-Naumann-Stiftung: „Palantir: Wie eine US-Software den Rechtsstaat zur Blackbox macht" – https://www.freiheit.org/de/deutschland/palantir-wie-eine-us-software-den-rechtsstaat-zur-blackbox-macht
11. Police-IT: „Palantir" (Archiv mit Section-702-Zusammenhang) – https://police-it.net/category/akteure/it_anbieter/palantir
12. Heise Online: „Europol nutzt Palantirs Big-Data-Software Gotham" – https://www.heise.de/news/Neue-Ermittlungsansaetze-Europol-nutzt-Palantirs-Big-Data-Software-Gotham-4781409.html
13. Data Center Dynamics: „Human rights groups call on AWS to stop hosting massive DHS biometric surveillance system" – https://www.datacenterdynamics.com/en/news/human-rights-groups-call-on-aws-to-stop-hosting-massive-dhs-biometric-surveillance-system/
14. NILC: „Homeland Advanced Recognition Technology (HART) Factsheet" – https://www.nilc.org/wp-content/uploads/2021/12/HART-factsheet-2021-11-10.pdf
15. Staatsanzeiger Baden-Württemberg: „Palantir im Südwesten: Was die Polizei-Software bedeutet" (November 2025) – https://www.staatsanzeiger.de/nachrichten/politik-und-verwaltung/palantir-im-suedwesten-was-die-polizei-software-bedeutet/

Dieser Artikel ist Teil einer Serie über den US-Überwachungsapparat und seine Auswirkungen auf europäische Bürger. Die vorangegangenen Artikel behandeln den CLOUD Act und FISA Section 702. Die dargestellten Einschätzungen basieren auf aktuellen Gerichtsurteilen, Berichten von Aufsichtsbehörden und Analysen anerkannter Bürgerrechtsorganisationen (EFF, GFF, CCC, Campact, EPIC), ersetzen jedoch keine individuelle Rechtsberatung. Stand: Februar 2026.

The post Palantir, die Sehsteine der USA in Europa appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was Google vorhat

Im August 2025 hat Google angekündigt, dass ab September 2026 keine Anwendung mehr auf zertifizierten Android-Geräten installiert werden kann, wenn der Entwickler sich nicht zuvor bei Google registriert und verifiziert hat. Das gilt nicht nur für Apps aus dem Play Store – sondern für sämtliche Installationswege, einschliesslich Sideloading und alternative App-Stores wie F-Droid.

Konkret verlangt Google von Entwicklern:

• Die Zahlung einer Gebühr
• Die Zustimmung zu Googles Nutzungsbedingungen
• Die Vorlage eines amtlichen Ausweises (Identitätsverifizierung)
• Den Nachweis über den privaten Signaturschlüssel
• Eine vollständige Liste aller aktuellen und zukünftigen App-Kennungen (Package Names)

Der Rollout soll zunächst in Brasilien, Indonesien, Singapur und Thailand beginnen. Ab 2027 plant Google die weltweite Einführung – also auch in Europa und der Schweiz.

Googles Argumentation – und warum sie nicht überzeugt

Google begründet die Massnahme mit Sicherheit. Laut eigener Analyse enthalten Apps aus Sideloading-Quellen angeblich fünfzigmal mehr Malware als Apps aus dem Play Store. Die Verifizierung soll verhindern, dass böswillige Akteure anonym schädliche Apps verbreiten.

Das klingt auf den ersten Blick nachvollziehbar, hält einer genaueren Prüfung allerdings nicht stand. Denn die Identitätsverifizierung prüft nur, wer der Entwickler ist – nicht, was die App tut. Ein verifizierter Entwickler kann weiterhin problemlos Malware verbreiten. Kriminelle werden schlicht gestohlene Identitäten nutzen oder den Verifizierungsprozess als triviale Hürde betrachten, da sie ohnehin bereits Gesetze brechen. Gleichzeitig werden legitime Entwickler abgeschreckt, die ihre Privatsphäre schützen wollen oder sich nicht von Google abhängig machen möchten.

F-Droid bringt es auf den Punkt: Vertrauen entsteht nicht dadurch, dass man die rechtliche Identität eines Entwicklers überprüft. Ob eine App schädlich ist oder nicht, lässt sich dadurch nicht feststellen – unabhängig davon, ob der Entwickler bei Google verifiziert ist. Die Art, wie F-Droid freie Software direkt aus dem Quellcode baut und an Nutzer verteilt, entspricht dem Prinzip, nach dem die meisten Linux-Distributionen seit Jahrzehnten Software ausliefern, wenn auch mit einigen Nachteilen. Diese Verteilungsmechanismen haben sich über Jahrzehnte bewährt, gelten als extrem sicher und bilden das Rückgrat der modernen Computing-Infrastruktur weltweit. Niemand hat je vorgeschlagen, dass Linux-Distributionen sicherer werden, indem eine zentrale Instanz jeden Entwickler verifiziert.

Was das für Verbraucher bedeutet

Wer ein Android-Gerät gekauft hat, tat dies im Vertrauen auf das Versprechen einer offenen Plattform, auf der jede beliebige Software ausgeführt werden kann. Ab September 2026 wird Google jedoch ohne Zustimmung der Nutzer ein Betriebssystem-Update ausspielen, das dieses Recht dauerhaft einschränkt. Ab diesem Zeitpunkt entscheidet Google, welchen Anwendungen ihr „vertrauen dürft" – und welchen nicht.

Besonders brisant: Diese Änderung betrifft zertifizierte Android-Geräte, also praktisch alle handelsüblichen Smartphones und Tablets, die mit Google-Apps und Play Protect ausgeliefert werden. Das schliesst Samsung, Xiaomi, OnePlus, Motorola, Google Pixel und unzählige weitere Hersteller ein.

Was das für Entwickler bedeutet

Für Entwickler wird es unmöglich, Anwendungen zu erstellen und direkt mit Freunden, Familie oder der eigenen Community zu teilen, ohne zuvor Googles Genehmigung einzuholen. Das ursprüngliche Versprechen von Android – das wichtigste Argument, mit dem sich das System einst vom iPhone abhob – beruhte auf seiner Offenheit. Offenbar ist Google inzwischen überzeugt, genug Kontrolle über das Android-Ökosystem zu besitzen, um dieses Prinzip nun aufzugeben.

Für die Open-Source-Gemeinschaft ist die Lage besonders kritisch. F-Droid, der wichtigste alternative App-Store für freie und quelloffene Android-Software, kann seine Entwickler nicht dazu zwingen, sich bei Google zu registrieren und dafür zu bezahlen. Gleichzeitig kann F-Droid die App-Kennungen nicht einfach übernehmen, da dies faktisch die exklusiven Vertriebsrechte für diese Anwendungen an sich reissen würde. F-Droid hat unmissverständlich erklärt: Googles Registrierungsdekret wird das F-Droid-Projekt und andere freie Distributionsquellen in ihrer heutigen Form beenden.

Was das für Staaten und die digitale Souveränität bedeutet

Regierungen, die sich auf Android-Geräte in der Verwaltung verlassen, überlassen die Kontrolle über die Rechte ihrer Bürger und ihre digitale Souveränität einem US-Konzern. Einem Konzern, der bekannt dafür ist, sich auch aussegerichtlichen Forderungen autoritärer Regime zu beugen, um missliebige – aber völlig legale – Anwendungen zu entfernen. Die für Verwaltung und Wirtschaft unverzichtbare Software wird damit den Launen eines fernen, unkontrollierbaren Unternehmens ausgeliefert.

Gerade für europäische Länder, die sich intensiv um digitale Souveränität bemühen, wäre diese Entwicklung ein herber Rückschlag. Der Digital Markets Act (DMA) der EU soll genau solche Machtkonzentration verhindern – doch ob er gegen Googles Pläne greifen wird, ist noch offen.

Hat Google bei der Entwicklerverifizierung „nachgegeben"

Ende 2025 deutete Google in einem Blogbeitrag vage an, dass es einen „erweiterten Ablauf" geben könnte, der es „erfahrenen Nutzern" eventuell erlaubt, „die Risiken der Installation nicht verifizierter Software zu akzeptieren". Viele Medien berichteten daraufhin, Google habe eingelenkt.

Die Realität sieht anders aus. Googles offizielle Entwicklerseite stellt weiterhin unmissverständlich fest:

Ab September 2026 müssen alle Android-Apps von bestätigten Entwicklern registriert werden, damit sie auf zertifizierten Android-Geräten installiert werden können.

Solange Google keine konkreten Belege dafür vorgelegt hat, dass es möglich sein wird, den Verifizierungsprozess ohne unangemessene Hürden zu umgehen, sollte man dem Glauben schenken, was auf der offiziellen Seite steht: Alle Apps von nicht registrierten Entwicklern werden blockiert.

Custom ROMs sind nicht betroffen – aber das reicht nicht

Ein wichtiger technischer Aspekt: Die Verifizierungspflicht betrifft ausschliesslich zertifizierte Android-Geräte – also solche, die mit Google Mobile Services (GMS) und dem Play-Protect-Framework ausgeliefert werden. Geräte mit Custom ROMs wie GrapheneOS, LineageOS, CalyxOS, /e/OS oder anderen AOSP-basierten Systemen ohne Google-Dienste sind von dieser Einschränkung nicht direkt betroffen. Auf diesen Systemen können weiterhin beliebige APKs installiert werden.

Das klingt zunächst beruhigend – ist es aber nur bedingt. Denn die überwältigende Mehrheit der Android-Nutzer verwendet Standard-Firmware mit Google-Diensten. Custom ROMs sind selbst unter technisch versierten Nutzern eine Nischenerscheinung. Nicht jeder kann oder will sein Gerät mit einem Custom ROM betreiben – sei es wegen mangelnder technischer Kenntnisse, fehlender Geräteunterstützung oder weil bestimmte Apps (Banking, Firmensoftware) ein zertifiziertes Gerät voraussetzen.

Zudem nutzen auch viele Anwender auf Stock-Android bewusst F-Droid und Apps von freien Entwicklern als Ergänzung oder Alternative zum Play Store. Genau diese Nutzer werden durch die neuen Regeln direkt betroffen sein. Es ist daher wichtig, sich auch dann für die Offenheit von Android einzusetzen, wenn man selbst ein Custom ROM nutzt – denn die Vielfalt des Ökosystems lebt davon, dass freie Software auf allen Android-Geräten installiert werden kann, nicht nur auf einer Handvoll Enthusiasten-Geräten.

Es gibt zudem ein weiteres Risiko: Wenn mehr Nutzer auf Custom ROMs ausweichen, um die Verifizierungspflicht zu umgehen, steigt paradoxerweise die Angriffsfläche. Denn das Entsperren des Bootloaders – bei den meisten Geräten die Voraussetzung für ein Custom ROM – deaktiviert die vom Hersteller etablierte Vertrauenskette auf Hardwareebene. Nur wenige Security-fokussierte ROMs wie GrapheneOS unterstützen das erneute Sperren des Bootloaders nach der Installation. Bei allen anderen Geräten bleibt der Bootloader entsperrt – mit entsprechenden Risiken.

Wie ihr helfen könnt

Als Entwickler

Registriert euch nicht für Googles Early-Access-Programm, führt keine Identitätsprüfung durch und akzeptiert keine Einladungen zur Android-Entwicklerkonsole. Nur durch das Einverständnis der Entwickler kann Googles Plan gelingen. Ermutigt andere Entwickler und Organisationen, sich ebenfalls nicht zu registrieren. Nutzt Community-Foren, soziale Netzwerke und Blogs, um die Botschaft zu verbreiten. Die Bibliothek FreeDroidWarn kann in eigene Projekte eingebunden werden, um Nutzer direkt in der App über die Problematik zu informieren.

Als Nutzer

• Installiert F-Droid auf euren Android-Geräten. Je mehr Nutzer alternative Plattformen verwenden, desto schwieriger wird es, sie auszuschliessen.
• Gebt Google direkt Feedback über die Umfrage zu den Anforderungen der Android-Entwicklerverifizierung.
• Macht eure Meinung öffentlich – in sozialen Netzwerken, Foren und Blogs. Verlinkt dabei auf keepandroidopen.org.
• Widersprecht Meinungsmanipulation: Wenn ihr in Foren oder sozialen Medien verdächtige Beiträge seht, die die neue Politik verteidigen, bezieht Stellung.
• Unterschreibt die Petition auf change.org.

Aufsichtsbehörden kontaktieren

Regulierungsbehörden auf der ganzen Welt sind ernsthaft besorgt über Monopole und die zunehmende Machtkonzentration im Technologiesektor. Beschwerden sind besonders wirksam, wenn sie von Bürgern des jeweiligen Landes eingereicht werden und in der Amtssprache verfasst sind.

Für die Europäische Union:

• E-Mail an das DMA-Team: EC-DMA@ec.europa.eu
• E-Mail Antitrust: COMP-GREFFE-ANTITRUST@ec.europa.eu
• Beschwerde bei der EU-Wettbewerbspolitik

Für die Schweiz:

• Meldung bei der Wettbewerbskommission (WEKO)

Warum das alle angeht

Was Google hier plant, geht weit über eine technische Änderung hinaus. Es ist ein fundamentaler Bruch mit dem Prinzip, das Android seit seiner Einführung definiert hat: Offenheit. Wenn ein einzelnes Unternehmen entscheiden kann, welche Software auf dem weltweit meistgenutzten Betriebssystem installiert werden darf, hat das weitreichende Konsequenzen – für die Meinungsfreiheit, für den Wettbewerb, für die Innovation und für die digitale Selbstbestimmung jedes einzelnen Nutzers.

Android ist nicht irgendein Produkt. Es läuft auf über drei Milliarden Geräten weltweit. Für viele Menschen – besonders in Entwicklungsländern – ist das Smartphone der einzige Computer, den sie besitzen. Ihnen den Zugang zu freier Software zu verwehren, ist ein Angriff auf ihre digitale Autonomie.

Die Initiative „Keep Android Open" ruft daher alle auf: Informiert euch, erhebt eure Stimme und setzt euch für ein offenes Android ein – bevor es zu spät ist.

Weiterführende Links:

• Keep Android Open – Offizielle Seite
• F-Droid: Googles Entwicklerregistrierungsdekret
• F-Droid: Developer Verification Policy und der DMA
• EFF: Application Gatekeeping – Ein wachsender Weg zur Internetzensur
• ACLU: Your Smartphone, Their Rules
• Heise: Keep Android Open – Abwehr gegen Verbot anonymer Apps von Google

The post Keep Android Open – Google will Android schliessen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist FISA Section 702

Section 702 wurde 2008 als Teil des FISA Amendments Act verabschiedet – in der politischen Atmosphäre nach den Anschlägen vom 11. September 2001. Der offizielle Zweck: Die gezielte Überwachung von Nicht-US-Bürgern außerhalb der USA, um Informationen über Terrorismus, Spionage und die Verbreitung von Massenvernichtungswaffen zu sammeln.

Klingt erst einmal spezifisch und kontrolliert. Doch die Realität sieht völlig anders aus.

Section 702 erlaubt es dem US-Justizminister und dem Direktor der Nationalen Nachrichtendienste, gemeinsam breite Überwachungsprogramme zu genehmigen. Das geheime FISA-Gericht (Foreign Intelligence Surveillance Court, kurz FISC) prüft diese Programme nur auf einer übergeordneten, programmatischen Ebene – es genehmigt keine einzelnen Überwachungsziele. Sobald ein Programm genehmigt ist, können NSA, FBI und CIA eigenständig entscheiden, wen sie ins Visier nehmen. Einzige Bedingung: Das Ziel muss ein Nicht-US-Bürger sein, der sich vermutlich außerhalb der USA aufhält.

Das klingt nach einer Einschränkung. Aber genau hier beginnt das Problem für uns als Europäer.

PRISM und Upstream: Die zwei Säulen der Überwachung

Edward Snowden enthüllte 2013, was viele bereits ahnten: Unter Section 702 betreibt die NSA zwei massive Überwachungsprogramme.

PRISM (heute „Downstream Collection") ist das bekanntere der beiden Programme. Das FBI – als Vermittler zwischen NSA und Privatunternehmen – schickt sogenannte „Selektoren" (E-Mail-Adressen, Telefonnummern, andere Identifikatoren) an US-Technologieunternehmen und verpflichtet diese, alle Kommunikationen herauszugeben, die mit diesen Selektoren in Verbindung stehen. Betroffen sind Unternehmen wie Microsoft, Google, Apple, Meta (Facebook), Yahoo und YouTube. Laut dem FISC war PRISM im Jahr 2011 für rund 91 Prozent der etwa 250 Millionen Internetkommunikationen verantwortlich, die jährlich unter Section 702 erfasst werden.

Lest das nochmal: 250 Millionen Kommunikationen pro Jahr. Allein durch PRISM.

Upstream Collection geht noch einen Schritt weiter. Hier greift die NSA Kommunikationen direkt an der Internet-Backbone-Infrastruktur ab – also an den Glasfaserkabeln und Knotenpunkten, durch die der globale Datenverkehr fließt. Da etwa 80 Prozent des weltweiten Internetverkehrs irgendwann durch US-Infrastruktur geleitet wird, ist die Reichweite dieses Programms enorm. Wenn ihr eine E-Mail an einen Geschäftspartner in Brasilien schickt und diese über einen US-Server geroutet wird, kann die NSA sie abfangen.

Besonders brisant war die sogenannte „Abouts"-Erfassung: Dabei wurden nicht nur Kommunikationen erfasst, die an oder von einem Überwachungsziel gingen, sondern auch solche, die ein Überwachungsziel lediglich erwähnten. Die NSA hat diese Praxis 2017 offiziell eingestellt – aber der RISAA von 2024 hat die Tür für eine Wiedereinführung unter bestimmten Bedingungen offen gelassen.

Die „Nebenbei"-Erfassung: Warum Europäer keine Nebensache sind

Die US-Regierung betont gebetsmühlenartig, dass Section 702 nur auf Ausländer außerhalb der USA abzielt. Was sie weniger gern erwähnt: Bei der Überwachung dieser Ziele werden zwangsläufig auch die Kommunikationen all jener erfasst, die mit diesen Zielen in Kontakt stehen – darunter Millionen von US-Bürgern und Europäern.

Diese sogenannte „Incidental Collection" (nebenbei erfolgende Erfassung) ist alles andere als nebensächlich. Wenn ein europäischer Geschäftsmann mit einem ausländischen Partner kommuniziert, der zufällig auf einer Überwachungsliste steht, landen seine E-Mails, Nachrichten und Anrufe in den Datenbanken der US-Geheimdienste. Und selbst wenn keine direkte Verbindung zu einem Überwachungsziel besteht: Durch die Upstream-Erfassung an der Internet-Backbone werden Kommunikationen quasi im Vorbeigehen mitgelesen.

Für Nicht-US-Bürger gibt es dabei praktisch keinen Schutz. Section 702 gewährt keinerlei Rechte auf Information, Widerspruch oder gerichtliche Überprüfung für ausländische Staatsangehörige. Ihr wisst nicht, ob eure Daten erfasst wurden. Ihr könnt nicht dagegen klagen. Ihr werdet nie informiert.

Backdoor Searches: Wenn das FBI die eigenen Bürger ausspioniert

Doch es kommt noch schlimmer. Die unter Section 702 gesammelten Daten werden in riesigen Datenbanken gespeichert. Und hier beginnt ein Missbrauch, der selbst die Verfechter des Gesetzes in Erklärungsnot bringt.

Das FBI kann diese Datenbanken jederzeit mit den Namen, E-Mail-Adressen oder Telefonnummern von US-Bürgern durchsuchen – die sogenannten „Backdoor Searches" oder „U.S. Person Queries". Kein Durchsuchungsbefehl nötig. Kein Richter. Kein begründeter Verdacht. Einfach den Namen eintippen und die intimsten Kommunikationen lesen.

Die Zahlen sind erschütternd:

• 2021: Das FBI führte bis zu 3,4 Millionen solcher Durchsuchungen durch – in einem einzigen Jahr.
• 2024: Die offiziell gemeldete Zahl sank auf 5.518. Doch das FISA-Gericht stellte fest, dass FBI-Mitarbeiter eine „erweiterte Filterfunktion" nutzten, die zusätzliche, nicht protokollierte Durchsuchungen durchführte. Die tatsächliche Zahl bleibt unbekannt.

Unter den Betroffenen dieser Durchsuchungen befanden sich nachweislich: Teilnehmer von Black-Lives-Matter-Protesten, Verdächtige des 6. Januar 2021, Journalisten, Mitglieder des US-Kongresses, ein US-Senator, ein Staatssenator, ein Staatsrichter, politische Kommentatoren und 19.000 Spender einer einzigen Kongresskampagne.

Das Privacy and Civil Liberties Oversight Board (PCLOB) – die eigentlich zuständige Aufsichtsbehörde – stellte fest, dass es kaum Belege für den Nutzen dieser massenhaften Backdoor-Durchsuchungen gibt. In den wenigen dokumentierten Fällen, in denen sie tatsächlich hilfreich waren, hätte das FBI auch einen regulären Durchsuchungsbefehl erwirken oder sich auf bestehende Ausnahmen berufen können.

Das historische Urteil von 2024: Verfassungswidrig

Im Dezember 2024 fällte Richterin LaShann DeArcy Hall am U.S. District Court für den Eastern District of New York ein wegweisendes Urteil im Fall United States v. Hasbajrami: Die Backdoor-Durchsuchungen von Section-702-Daten verstoßen gegen den vierten Zusatzartikel der US-Verfassung und erfordern grundsätzlich einen richterlichen Durchsuchungsbefehl.

Es war das erste Mal überhaupt, dass ein Gericht diese Praxis für verfassungswidrig erklärte. Der Fall betraf einen US-Einwohner, der 2011 am New Yorker JFK-Flughafen verhaftet wurde. Erst nach seiner ursprünglichen Verurteilung offenbarte die Regierung, dass Teile der Beweismittel aus ohne Durchsuchungsbefehl durchgeführten Section-702-Abfragen stammten.

Die Regierung hat Berufung eingelegt. Aber das Urteil sendet ein klares Signal – auch für die anstehende Debatte um die Verlängerung von Section 702.

RISAA 2024: Mehr Überwachung statt Reform

Statt die dokumentierten Missbräuche einzudämmen, hat der US-Kongress im April 2024 mit dem Reforming Intelligence and Securing America Act (RISAA) Section 702 nicht nur verlängert, sondern ausgeweitet:

Erweiterte Definition von „Electronic Communication Service Provider": Jeder Dienstleister, der Zugang zu Geräten hat, die elektronische Kommunikationen übertragen oder speichern könnten, kann nun zur Kooperation gezwungen werden. Das betrifft potenziell nicht mehr nur klassische Telekommunikationsunternehmen und Internetanbieter, sondern auch Rechenzentren, Cloud-Dienste, Managed-Security-Anbieter – und theoretisch sogar Vermieter oder Wartungspersonal mit Zugang zu Netzwerkinfrastruktur. Senator Ron Wyden nannte dies „eine der dramatischsten und erschreckendsten Erweiterungen der staatlichen Überwachungsbefugnisse in der Geschichte."

Neue Überwachungszwecke: Die Definition von „Foreign Intelligence Information" wurde erweitert, um die internationale Produktion, Verteilung und Finanzierung illegaler Drogen einzuschließen – ein gewaltiger Schritt weg von der ursprünglichen Antiterrorismus-Begründung.

Immigrations-Screening: Section-702-Daten dürfen nun zur Überprüfung von Einwanderern und Asylsuchenden verwendet werden.

Was der RISAA nicht enthält: eine Pflicht zum richterlichen Durchsuchungsbefehl für Backdoor Searches. Ein entsprechender Änderungsantrag scheiterte im Repräsentantenhaus mit einem Gleichstand von 212 zu 212 Stimmen.

Die einzige gute Nachricht: Der RISAA verlängerte Section 702 nur um zwei Jahre. Am 20. April 2026 läuft das Gesetz aus. Es sei denn, der Kongress verlängert es erneut.

FISA Section 702 und die DSGVO: Ein unlösbarer Konflikt

Hier schließt sich der Kreis zu unserem CLOUD-Act-Artikel. Denn während der CLOUD Act es US-Behörden ermöglicht, gezielt Daten von US-Unternehmen anzufordern, geht Section 702 noch viel weiter: Es erlaubt die massenhafte, programmatische Erfassung von Kommunikationsdaten – ohne dass einzelne Ziele gerichtlich genehmigt werden müssen.

Der Europäische Gerichtshof (EuGH) hat in seinem Schrems-II-Urteil vom Juli 2020 unmissverständlich festgestellt, dass Section 702 nicht mit den Grundrechten der EU vereinbar ist. Der Gerichtshof stellte insbesondere fest, dass Section 702 „keinerlei Beschränkungen der damit übertragenen Überwachungsbefugnisse oder Garantien für Nicht-US-Bürger" enthält, die potenziell betroffen sind. Auch das Presidential Policy Directive 28 (PPD-28), das gewisse Einschränkungen für die Überwachung von Nicht-US-Bürgern vorschreibt, wurde vom EuGH als unzureichend bewertet.

Das hat direkte Konsequenzen für europäische Unternehmen. Wenn ihr personenbezogene Daten eurer Kunden, Mitarbeiter oder Geschäftspartner über US-Dienste verarbeitet – sei es Microsoft 365, Google Workspace, AWS oder Salesforce –, dann sind diese Daten potenziell der Überwachung durch Section 702 ausgesetzt. Und das steht in direktem Widerspruch zur DSGVO, die einen „gleichwertigen Schutz" bei Datentransfers in Drittländer verlangt.

Das Trans-Atlantic Data Privacy Framework (TADPF), das Nachfolgeabkommen des gescheiterten Privacy Shield, steht bereits vor dem nächsten juristischen Angriff durch Max Schrems und noyb. Der Datenschutzaktivist hat darauf hingewiesen, dass die tatsächlichen Überwachungsgesetze der USA – allen voran Section 702 – sich durch das Framework nicht geändert haben. Seine Einschätzung: Das TADPF wird denselben Weg gehen wie Safe Harbor und Privacy Shield.

CLOUD Act + Section 702: Die doppelte Bedrohung

Um die Tragweite zu verstehen, müsst ihr den CLOUD Act und Section 702 zusammen betrachten:

Zusammen bilden diese beiden Gesetze ein lückenloses System: Der CLOUD Act gewährt den Zugriff auf gespeicherte Daten bei US-Unternehmen. Section 702 erlaubt das massenhafte Abfangen von Kommunikationen in Echtzeit. Egal ob eure Daten auf einem Microsoft-Server in Frankfurt liegen oder eure E-Mail über ein US-Backbone geroutet wird – die US-Regierung hat einen Weg, darauf zuzugreifen.

Die Aufsicht bröckelt

Selbst die ohnehin schwachen Kontrollmechanismen werden zunehmend ausgehöhlt. Das Privacy and Civil Liberties Oversight Board (PCLOB), das als zentrale Aufsichtsinstanz die Einhaltung der Bürgerrechte bei Überwachungsprogrammen überprüfen soll, wurde Anfang 2025 faktisch handlungsunfähig gemacht. Die demokratischen Mitglieder wurden entlassen, das Gremium besteht nun aus einem einzigen Teilzeit-Mitglied. Gleichzeitig wurde das Office of Internal Auditing des FBI – im Jahr 2020 eigens geschaffen, um Missbrauch zu verhindern – aufgelöst.

Das bedeutet: Die Mechanismen, die Missbrauch verhindern sollen, werden gerade systematisch abgebaut – während die Überwachungsbefugnisse gleichzeitig ausgeweitet werden.

Was ihr tun könnt: Praktische Schritte

Angesichts dieser Situation gibt es für europäische Privatpersonen und Unternehmen nur eine logische Konsequenz: Reduziert eure Abhängigkeit von US-Infrastruktur und US-Software.

Für eure Kommunikation: Signal oder andere Ende-zu-Ende-verschlüsselte Messenger sind unverzichtbar. Beachtet jedoch: Der EuGH hat angemerkt, dass US-Behörden unter Section 702 theoretisch auch kryptographische Schlüssel von US-Unternehmen anfordern könnten. Deshalb sind europäische Alternativen wie Threema oder Matrix/Element vorzuziehen.

Für eure Daten: Self-Hosting mit europäischer Software – etwa Nextcloud auf europäischen Servern – entzieht eure Daten vollständig der US-Jurisdiktion. Wie wir in unserem CLOUD-Act-Artikel erklärt haben: Entscheidend ist nicht, wo die Daten liegen, sondern wer sie kontrolliert. Eine selbst gehostete Lösung bei einem europäischen Anbieter ist der sicherste Weg.

Für eure E-Mails: Europäische E-Mail-Anbieter wie Tuta (ehemals Tutanota) oder Proton Mail unterliegen nicht der US-Jurisdiktion und bieten Ende-zu-Ende-Verschlüsselung.

Für euer Unternehmen: Führt eine Datentransfer-Folgenabschätzung (Transfer Impact Assessment) durch. Prüft, welche eurer Dienste US-Unternehmen sind oder Daten über US-Infrastruktur routen. Und dokumentiert diese Risiken – nicht nur für die DSGVO-Compliance, sondern für das Vertrauen eurer Kunden.

Fazit: Die Uhr tickt

Section 702 läuft am 20. April 2026 aus. Die nächsten Monate werden zeigen, ob der US-Kongress endlich grundlegende Reformen verabschiedet – etwa eine Pflicht zum richterlichen Durchsuchungsbefehl für den Zugriff auf Kommunikationen von US-Bürgern – oder ob das Gesetz erneut verlängert oder sogar ausgeweitet wird.

Aber selbst wenn Section 702 reformiert würde: Für europäische Bürger ändert sich wenig. Die Debatte in Washington dreht sich ausschließlich um die Rechte von US-Bürgern. Nicht-US-Bürger haben unter Section 702 keinerlei Schutz – und daran wird sich auch durch Reformen nichts ändern.

Die einzige Lösung für Europäer liegt nicht in Washington. Sie liegt in unseren eigenen Händen: in der konsequenten Nutzung eigener Infrastruktur, selbst gehosteter OpenSource Software und europäischer Dienste die sich dem Datenschutz gewidmet haben. Digitale Souveränität ist kein Luxus – sie ist die logische Antwort auf ein Überwachungssystem, das uns als Europäer ganz bewusst ohne jeden Rechtsschutz lässt.

Quellen und weiterführende Links

1. Brennan Center for Justice: „Section 702 of the Foreign Intelligence Surveillance Act (FISA): A Resource Page" – https://www.brennancenter.org/our-work/research-reports/section-702-foreign-intelligence-surveillance-act-fisa-resource-page
2. Electronic Frontier Foundation (EFF): „Upstream vs. PRISM" – https://www.eff.org/pages/upstream-prism
3. Congressional Research Service: „FISA Section 702 and the 2024 Reforming Intelligence and Securing America Act" – https://www.congress.gov/crs-product/R48592
4. EFF: „U.S. Senate and Biden Administration Shamefully Renew and Expand FISA Section 702" – https://www.eff.org/deeplinks/2024/04/us-senate-and-biden-administration-shamefully-renew-and-expand-fisa-section-702-0
5. Center for Democracy and Technology (CDT): „Four Reasons FISA 702 Still Needs a Warrant Rule for US Person Queries" – https://cdt.org/insights/four-reasons-fisa-702-still-needs-a-warrant-rule-for-us-person-queries/
6. Just Security: „Court Says Warrant Needed for U.S. Person Queries of FISA Section 702 Data" – https://www.justsecurity.org/106895/warrant-needed-fisa-section-702/
7. Electronic Privacy Information Center (EPIC): „Reforming 702: End Warrantless Backdoor Searches" – https://epic.org/reforming-702-end-warrantless-backdoor-searches/
8. Norton Rose Fulbright: „Schrems II landmark ruling: A detailed analysis" – https://www.nortonrosefulbright.com/en-us/knowledge/publications/ad5f304c/schrems-ii-landmark-ruling-a-detailed-analysis
9. EPIC v. DOJ – PRISM: Hintergründe zum PRISM-Programm – https://epic.org/documents/epic-v-doj-prism/
10. Cybersecurity Magazine: „FISA – A Catalyst for Europe's Cybersecurity Sovereignty" – https://cybersecurity-magazine.com/fisa-a-catalyst-for-europes-cybersecurity-sovereignty/
11. Federalist Society: „Reforming Section 702: Should the FBI Require a Warrant?" – https://fedsoc.org/briefcase/reforming-section-702-should-the-fbi-require-a-warrant-to-search-its-database-for-the-communications-of-us-persons
12. Information Technology Industry Council (ITI): „Expansion of FISA Electronic Communications Service Provider Definition Must Be Removed" – https://www.itic.org/news-events/techwonk-blog/expansion-of-fisa-electronic-communications-service-provider-definition-must-be-removed
13. Fieldfisher: „US surveillance: s702 FISA, EO 12333, PRISM and UPSTREAM" – https://www.fieldfisher.com/en/insights/us-surveillance-s702-fisa-eo-12333-prism-and-ups
14. State of Surveillance: „Section 702: The Law That Lets Feds Search Your Messages Without a Warrant" – https://stateofsurveillance.org/articles/government/section-702-fisa-warrantless-surveillance/

The post FISA Section 702: Das unsichtbare Netz der US-Massenüberwachung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Linux bietet mit Swap und zRAM sehr effektive Werkzeuge, um genau solche Situationen deutlich zu entschärfen. Richtig eingerichtet sorgen sie dafür, dass das System stabil bleibt, weniger einfriert und sich insgesamt flüssiger anfühlt – selbst bei knappen RAM-Ressourcen.

Dieses Tutorial erklärt:

• was Swap und zRAM sind
• worin der Unterschied liegt
• warum die Kombination sinnvoll ist
• wie man beides korrekt einrichtet
• wie man überprüft, ob alles richtig funktioniert

Das Ganze ist bewusst einsteigerfreundlich, aber technisch korrekt gehalten.

Was ist Swap

Swap ist Auslagerungsspeicher. Wenn der physische Arbeitsspeicher (RAM) knapp wird, kann Linux Speicherbereiche auf ein langsameres Medium auslagern – meist eine SSD oder HDD.

Vorteile von Swap

• verhindert Abstürze durch Speichermangel (OOM-Killer)
• sorgt dafür, dass das System weiterläuft
• ideal als Sicherheitsnetz

Nachteile von Swap

• deutlich langsamer als RAM
• kann bei starker Nutzung zu Rucklern führen

Swap ist wichtig, aber allein nicht optimal für Performance.

Was ist zRAM

zRAM ist komprimierter Arbeitsspeicher.

Dabei wird ein Teil des RAMs als komprimiertes Blockgerät genutzt. Daten werden also nicht auf die Festplatte, sondern komprimiert im RAM selbst abgelegt.

Vorteile von zRAM

• extrem schnell (bleibt im RAM)
• sehr gut komprimierbar (oft 1.5–2.5×)
• ideal für inaktive Speicherbereiche
• reduziert SSD-Swap massiv

Nachteile von zRAM

• benötigt etwas CPU-Leistung
• kann keinen echten RAM ersetzen

zRAM ist kein Ersatz für RAM, aber ein sehr effizienter Puffer.

Warum Swap UND zRAM kombinieren

Die beste Lösung ist eine zweistufige Speicherstrategie:

1. zRAM als schneller, komprimierter Zwischenspeicher
2. klassischer Swap als Notfallreserve

Linux nutzt automatisch zuerst den Swap mit der höheren Priorität – also zRAM – und greift nur im Ernstfall auf die SSD zurück.

Ergebnis:

• weniger Freezes
• stabileres Multitasking
• deutlich bessere Reaktionsfähigkeit

Schritt 1: Vorhandenen Swap prüfen

swapon --show

oder:

free -h

Wenn kein Swap vorhanden ist oder ihr neu starten wollt, geht es weiter mit Schritt 2. Solltet ihr bereits eine Swap Partition haben, überspringt Schritt 2, und macht weiter mit Schritt 3.

Schritt 2: Swapfile anlegen (Beispiel: 4 GB)

Gebt diese Befehle einzeln in die Konsole ein:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Danach dauerhaft aktivieren in der fstab Datei:

sudo nano /etc/fstab

Eintrag hinzufügen:

/swapfile none swap sw 0 0

Speichern mit strg+o und beenden mit strg-x

Schritt 3: zRAM installieren

Unter Ubuntu, KDE Neon und ähnlichen Debian Systemen:

sudo apt install zram-tools

Konfiguration öffnen:

sudo nano /etc/default/zramswap

Empfohlene Grundeinstellung am Ende der Datei setzen:

ENABLED=true
PERCENT=40
PRIORITY=100

Erklärung:

• PERCENT=40 → 40 % des RAMs als zRAM
• PRIORITY=100 → zRAM wird vor dem Swap genutzt

Dienst neu starten:

sudo systemctl restart zramswap

Schritt 4: Swappiness sinnvoll setzen

Swappiness steuert, wie früh Linux Swap nutzt, sollte der Arbeitspeicher eine bestimmte Auslastung erreichen.

Empfehlung für Desktop + wenig RAM:

sudo sysctl vm.swappiness=80

Dauerhaft:

sudo nano /etc/sysctl.conf

Eintrag:

vm.swappiness=80

Danach die Einstellungen mit:

sudo sysctl -p

direkt aktivieren

Schritt 5: Überprüfen, ob alles korrekt läuft

Swap-Status anzeigen

swapon --show

Erwartetes Ergebnis:

• zRAM mit hoher Priorität
• Swapfile mit niedriger Priorität

/dev/zram0

• 6 GB zRAM → passt zu PERCENT=40
• PRIO 100 → wird immer zuerst benutzt
• USED 0B → aktuell genug RAM, kein Druck

/swapfile

• 4 GB SSD-Swap
• PRIO -2 → klassischer Fallback
• wird erst benutzt, wenn zRAM voll ist

Genau die richtige Reihenfolge, die Einstellungen sind korrekt gesetzt.

Speicherverhalten beobachten

free -h

oder live:

watch -n 1 swapon --show

Gesundes Verhalten:

• zRAM wird genutzt
• SSD-Swap bleibt möglichst leer
• System bleibt bedienbar

Typische Empfehlungen nach RAM-Größe

4–8 GB RAM

• zRAM: 50 %
• Swapfile: 2–4 GB

16 GB RAM

• zRAM: 30–40 %
• Swapfile: 4–8 GB

32 GB RAM

• zRAM: optional
• Swapfile: klein oder nur als Fallback

Fazit

Swap und zRAM sind keine Notlösungen, sondern bewusst entwickelte Werkzeuge im Linux-Kernel.

Richtig kombiniert sorgen sie für:

• mehr Stabilität
• weniger Einfrieren
• bessere Alltagstauglichkeit

Gerade auf Systemen mit wenig RAM ist diese Konfiguration oft der größte Performance-Gewinn ohne neue Hardware.

Wenn trotz zRAM und Swap dauerhaft alles ausgelastet ist, gilt trotzdem: Kein Tuning ersetzt fehlenden Arbeitsspeicher. Aber bis zu diesem Punkt holt diese Methode das Maximum aus eurem System heraus.

The post Mehr Leistung bei wenig RAM: Swap & zRAM unter Linux appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitung

Sichert zunächst eure wichtigen Daten. Das sollte ohnehin regelmäßig geschehen, aber vor einem Major-Upgrade ist es besonders ratsam.

Aktualisiert das System auf den neuesten Stand, entweder über die integrierte Updateverwaltung:

Oder über das Terminal mit den Befehlen:

sudo apt update
sudo apt full-upgrade

Startet das System neu nachdem alles geupdated wurde.

sudo reboot

Methode 1: GUI-Upgrader (Desktop)

Öffnet die Anwendung Software-Aktualisierung (oder Update Manager). Ubuntu sollte euch aber auch automatisch mitteilen, dass eine neue Version (24.04) verfügbar ist.

Klickt auf System jetzt aktualisieren und folgt dem Assistent. Das System wird dann alle notwendigen Schritte automatisch ausführen. Das kann eine Weile dauern.

Falls ihr nicht direkt informiert werdet, dass eine Systemaktualisierung bereit stellt, bekommt ihr die Meldung mit einem Klick auf die Aktuliasierungsverwaltung.

Klickt in diesem Falle auf Aktualisieren...

Hier bekommt die Veröffentlichungshinweise, lest diese durch, falls interessiert.

Klickt als nächstes auf System aktualisieren.

Das System beginnt mit den Vorbereitungen der Aktualisierung und leitet alle nötigen Schritte ein.

Danach werdet ihr nochmals informiert, was alles geupdated wird, und danach gehts weiter mit der eigentlichen Aktualisierung:

Während des Upgrades informiert euch Ubuntu, das einige Pakete, hier zum Beispiel Thunderbird zukünftig nur noch als Snap Paket erhältlich ist, und zwingt euch unfreiweilig in ihr proprietäres Snap Ökosystem.

Bestätigt mit Weiter.

Falls ihr individuelle Konfigurationen an bestimmten Systemdateien getätigt habt, wird Ubuntu euch fragen, was mit diesen geschehen soll:

Klickt auf Beibehalten, wenn ihr individuelle Konfigurationen übernehmen wollt, oder Ersetzen falls ihr nie was an diesen Dateien verändert habt.

Anschliessend werdet ihr gefragt, ob ihr die veralteten Pakete entfernen wollt, der Ordnung halber entfernt ihr diese natürlich. Falls eurer Rechner nicht von 2005 sein sollte, geht das natürlich nicht mehrere Stunden.

Nach dem Upgrade startet ihr System neu und ihr seid nun auf Ubuntu 24.04 LTS.

Methode 2: Terminal mit do-release-upgrade

Diese Methode ist für diejenigen, die gerne im Terminal arbeiten oder die Kenntnisse darin vertiefen möchten. Sie funktioniert sowohl auf Desktop- als auch auf Server-Systemen.

Öffnet ein Terminal und gebt Folgendes ein:

sudo do-release-upgrade

Das System prüft automatisch, ob ein Upgrade verfügbar ist. Wenn ja, werden euch die Changelog und Upgrade-Details angezeigt.

Bestätigt mit y (yes), um fortzufahren:

Do you want to start the upgrade? [Y/n]

Das Upgrade lädt nun Pakete herunter und aktualisiert sie. Bei Rückfragen zu Konfigurationsdateien (z.B. von SSH oder anderen Services) werden euch Optionen angeboten:

• keep – Behaltet eure aktuelle Konfiguration
• install – Nutzt die neue Konfiguration von Ubuntu
• see diff – Zeigt die Unterschiede an

Für die meisten Nutzer ist es sicher, keep (N) zu wählen, wenn ihr Anpassungen gemacht habt.

Nach Abschluss werden alte, nicht mehr benötigte Pakete entfernt. Das System fordert euch auf, neu zu starten:

sudo reboot

Nach dem Neustart seid ihr auf Ubuntu 24.04.

Überprüfung nach dem Upgrade

Prüft die Ubuntu-Version:

lsb_release -a

Das sollte anzeigen:

Release: 24.04
Codename: noble

Bereinigt noch alte Paketdateien:

sudo apt autoremove
sudo apt autoclean

Troubleshooting: Was kann schiefgehen?

do-release-upgrade findet keine neue Version

Das passiert, wenn das System nicht auf dem neuesten Stand ist. Versucht:

sudo do-release-upgrade -d

Das -d erzwingt das Upgrade auf die nächste verfügbare Version.

Falls immer noch nichts passiert, prüft eure Repositories:

cat /etc/apt/sources.list

Achtet darauf, dass keine exotischen PPAs (Personal Package Archives) aktiviert sind, die das Upgrade blockieren.

Paketkonflikte während des Upgrades

Das Terminal zeigt euch dann eine Frage zu Konfigurationsdateien. Nutzt see diff, um zu prüfen, was sich ändert. Im Zweifel: keep (N) wählen, um eure Einstellungen zu behalten.

Das System bricht während des Upgrades ab

Falls das Internet unterbricht oder etwas anderes schiefgeht, könnt ihr das Upgrade fortsetzen:

sudo do-release-upgrade

Das erkennt den unvollendeten Prozess und setzt fort.

Abhängigkeitsprobleme nach dem Upgrade

Falls das System nicht vollständig aktualisiert wurde, versucht:

sudo apt install -f
sudo apt full-upgrade

Das -f repariert unterbrochene Installationen.

PPAs verursachen Probleme

Manchmal blockieren externe PPAs (z.B. für proprietary Software) das Upgrade. Ihr könnt sie deaktivieren:

sudo add-apt-repository --remove ppa:paketname/ppa

Oder alle auf einmal mit ppa-purge:

sudo apt install ppa-purge
sudo ppa-purge ppa:paketname/ppa

Nach dem Entfernen könnt ihr es erneut versuchen:

sudo do-release-upgrade

Desktop-Umgebung (GNOME/KDE) funktioniert nicht

Falls euer Desktop nach dem Upgrade nicht mehr startet, versucht:

sudo apt install --reinstall ubuntu-desktop
# oder für KDE:
sudo apt install --reinstall kubuntu-desktop

Meldet euch ab, wählt beim Login die richtige Umgebung und meldet euch wieder an.

Netzwerk funktioniert nach dem Upgrade nicht

Das ist selten, kann aber passieren. Prüft die Netzwerk-Manager-Konfiguration:

sudo systemctl restart networking

Oder für systemd-based Systeme:

sudo systemctl restart systemd-networkd

Fazit

Das Upgrade von 22.04 auf 24.04 ist ein relativ unkomplizierter Prozess. Nutzt die Terminal-Methode mit do-release-upgrade – sie ist transparenter, zuverlässiger und funktioniert überall gleich gut, ob auf Desktop oder Server. Mit etwas Geduld und den richtigen Antworten zu Konfigurationsfragen ist das System schnell auf dem neuesten Stand.

Viel Erfolg beim Upgrade!

The post Ubuntu 22.04 auf 24.04 upgraden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Mit Immich steht dir ab sofort ein moderner, leistungsfähiger und datenschutzfreundlicher Foto- und Video-Dienst zur Verfügung. Der Service richtet sich an alle, die ihre Erinnerungen sicher speichern, komfortabel verwalten und jederzeit abrufen möchten – ohne Abhängigkeit von kommerziellen Cloud-Anbietern.

Im Gegensatz zu bekannten Plattformen wie Google Photos oder iCloud bleibt bei Immich die volle Kontrolle über deine Daten erhalten. Es gibt kein Tracking, keine Profilbildung, keine Weitergabe an Werbenetzwerke. Deine Fotos und Videos werden ausschließlich innerhalb dieses Dienstes verarbeitet.

📸 Automatische Backups von Smartphone & Desktop

Immich bietet mobile Apps für Android und iOS, mit denen Fotos und Videos automatisch gesichert werden können. Neue Aufnahmen landen zuverlässig im persönlichen Archiv, ohne manuelles Hochladen oder komplizierte Workflows.
Zusätzlich steht eine Weboberfläche zur Verfügung, über die du deine Mediensammlung bequem vom Desktop aus verwalten kannst.

🗂️ Übersichtliche Organisation & intelligente Suche

Alle Medien werden automatisch nach Datum, Aufnahmezeit und Metadaten sortiert. Große Sammlungen bleiben übersichtlich, auch über Jahre hinweg.
Dank integrierter Analysefunktionen kannst du deine Fotos und Videos gezielt durchsuchen – etwa nach Motiven, Orten oder Personen – ohne dass Inhalte an externe Dienste gesendet werden.

👥 Alben & Teilen – kontrolliert und bewusst

Du kannst Alben erstellen und gezielt freigeben, etwa für Familie oder Freunde. Dabei behältst du jederzeit die Kontrolle darüber, wer was sehen darf. Keine öffentlichen Profile, keine unfreiwillige Sichtbarkeit, kein algorithmisches Ranking.

🔐 Datenschutz als Grundprinzip

Immich ist konsequent auf Privatsphäre ausgelegt:

• kein Zwang zu externen Accounts
• kein Tracking durch Drittanbieter
• keine Werbung
• keine Analyse zu Marketingzwecken

Der Dienst eignet sich besonders für Nutzer, die ihre persönlichen Erinnerungen nicht an große Konzerne auslagern möchten.

🌍 Zugriff von überall

Ob Smartphone, Tablet oder Desktop – deine Fotos und Videos sind jederzeit verfügbar. Die Oberfläche ist modern, schnell und auf den täglichen Gebrauch ausgelegt, auch bei sehr großen Mediensammlungen.

✅ Für wen ist Immich gedacht?

• für alle, die ihre Fotos sicher und langfristig speichern möchten
• für Familien mit gemeinsamen Fotoalben
• für datenschutzbewusste Nutzer
• für alle, die eine echte Alternative zu kommerziellen Cloud-Galerien suchen

3GB Speicher Gratis für alle

Deine persönliche Fotocloud bietet dir 3GB Speicher für deine Fotos und Videos.

The post Immich – Private Foto- & Video-Cloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wanderer ist ein offenes, leistungsfähiges Tool, mit dem du deine Aktivitäten rund um Trails, Pfade und Outdoor-Abenteuer zentral verwaltest. Die Oberfläche ist intuitiv gestaltet, sodass sowohl Hobby-Wanderer als auch erfahrene Outdoor-Communities ihre Touren einfach dokumentieren und planen können. (wanderer Documentation)

🧭 Was du mit Wanderer machen kannst

• 📍 GPS-Tracks hochladen – Lade GPX- oder TCX-Dateien hoch und speichere deine aufgezeichneten Wanderungen inklusive aller relevanten Infos wie Distanz, Höhenmeter oder Dauer. (wanderer Documentation)
• 🗺️ Routen erstellen & planen – Zeichne neue Trails direkt auf der Karte oder nutze moderne Routing-Tools zur Planung deiner nächsten Strecke. (wanderer Documentation)
• 📋 Metadaten hinzufügen – Ergänze Beschreibungen, Schwierigkeitsgrad, Geländeart, Tags oder Regionen zu deinen Trails für bessere Übersicht und Suche. (wanderer Documentation)
• 🔍 Trail-Sammlung durchsuchen – Organisiere, filtere und finde Routen schnell über Suchfunktionen und Kategorien. (wanderer Documentation)
• 🌄 Fotos & Erinnerungen integrieren – Mache deine Trails lebendig mit Fotos, Notizen oder Wegpunkten. (wanderer Documentation)

🤝 Soziale Funktionen & Fediverse-Integration

Wanderer bietet optionale soziale Features, damit du dich mit anderen Entdeckern vernetzen kannst. Du kannst:

• 🌐 anderen Nutzern folgen
• ❤️ Trails liken
• 💬 Kommentare hinterlassen
• 📬 Benachrichtigungen erhalten

Dank Federation (über ActivityPub) ist Wanderer außerdem kompatibel mit anderen föderierten Plattformen, sodass Interaktionen über Instanzgrenzen hinweg möglich sind – für eine vernetzte Outdoor-Community. (wanderer Documentation)

💡 Warum Wanderer nutzen?

• 🏞️ Ideal für Outdoor-Fans – perfekt für Wanderer, Trailrunner, Radfahrer oder alle, die draußen aktiv sind.
• 🔐 Datenschutz steht im Mittelpunkt – keine Werbung, kein Tracking, keine Weitergabe deiner Daten.
• 🌍 Einfache Nutzung – intuitiv bedienbar auf Desktop wie Mobilgeräten.
• 📈 Deine Abenteuer, dein Archiv – alles an einem Ort, übersichtlich gespeichert und leicht zugänglich.

Mit Wanderer geben wir dir ein mächtiges Werkzeug an die Hand, um deine Outdoor-Erlebnisse zu planen, zu archivieren und mit anderen Abenteurern zu teilen – datenschutzfreundlich, frei und ohne externe Datenkraken.

Probier es aus: ➜ wanderer.yourdevice.ch

The post Wanderer – Outdoor-Trail-Hub appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitung

Bevor ihr startet, macht eine Sicherung eurer wichtigen Daten. Das sollte ohnehin regelmäßig geschehen, aber vor einem Major-Upgrade ist es besonders ratsam.

Aktualisiert zunächst das System auf den neuesten Stand von Bookworm:

sudo apt update
sudo apt full-upgrade

Nach diesen Befehlen kann es nötig sein, den Rechner neuzustarten – befolgt die Aufforderungen des Systems.

Die Repository-Quellen anpassen

Das Herzstück des Upgrades: Ihr müsst alle Verweise auf „bookworm" in eurer apt-Quellenliste in „trixie" umwandeln.

Öffnet die Datei mit einem Editor eurer Wahl:

sudo nano /etc/apt/sources.list

(Alternativ geht auch sudo vi /etc/apt/sources.list oder ein anderer Editor.)

Sucht nach Zeilen, die „bookworm" enthalten, und ersetzt diesen Begriff durch „trixie". Typischerweise sieht es vorher so aus:

deb http://deb.debian.org/debian bookworm main contrib non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware

Danach sollte es so aussehen:

deb http://deb.debian.org/debian trixie main contrib non-free-firmware
deb-src http://deb.debian.org/debian trixie main contrib non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free-firmware
deb-src http://security.debian.org/debian-security trixie-security main contrib non-free-firmware

Speichert die Datei (in nano: Strg+O, Enter, dann Strg+X).

Prüft auch, ob weitere sources-Listen vorhanden sind:

ls -la /etc/apt/sources.list.d/

Wenn dort .list oder .sources-Dateien sind, müsst ihr auch dort „bookworm" durch „trixie" ersetzen.

Das eigentliche Upgrade

Jetzt aktualisiert die Paketlisten:

sudo apt update

Führt einen Testlauf durch, um zu sehen, welche Pakete aktualisiert werden:

sudo apt full-upgrade --dry-run

Wenn alles gut aussieht, startet das echte Upgrade:

sudo apt full-upgrade

Das kann eine Weile dauern. Der Prozess lädt große Mengen an Daten herunter und aktualisiert hunderte von Paketen. Bei Rückfragen des Systems (z.B. zu Konfigurationsdateien) empfiehlt es sich, die Standardoptionen zu wählen, außer ihr habt spezifische Änderungen an Dateien vorgenommen.

Wählt hier einfach immer N (keep your currently-installed version), und bestätigt mit Enter.

Nach dem Upgrade

Startet den Rechner neu:

sudo reboot

Prüft nach dem Start, dass alles lädt:

uname -r

Das sollte euch einen Kernel mit „trixie" anzeigen.

Bereinigt alte Pakete:

sudo apt autoremove
sudo apt autoclean

Troubleshooting: Was kann schiefgehen?

Paketkonflikte während des Upgrades

Manchmal zeigt apt an, dass Pakete nicht installiert werden können, weil Abhängigkeiten fehlen. Versucht in diesem Fall:

sudo apt --fix-broken install

Oder wartet mit dem Upgrade auf ein bestimmtes Paket, bis Abhängigkeiten geklärt sind. Das ist selten nötig, kommt aber vor.

„Unmet dependencies" Fehlermeldung

Falls apt weigert sich weiterzumachen, versucht:

sudo apt install -f

Das versucht, fehlende Abhängigkeiten automatisch zu beheben.

Einzelne Pakete verursachen Probleme

In seltenen Fällen kann ein einzelnes Paket das Upgrade blockieren. Ihr könnt es temporär „halten", bis der Rest aktualisiert ist:

sudo apt-mark hold paketname

Und später wieder freigeben:

sudo apt-mark unhold paketname

Das System startet nicht nach dem Upgrade

Das ist sehr selten. Falls es passiert:

• Startet von einem Debian Live USB
• Mounted die Root-Partition
• Repariert GRUB mit sudo grub-install /dev/sda (oder eure entsprechende Festplatte)

Desktop-Umgebung ist kaputt

Falls X11 oder euer Desktop nicht mehr startet, versucht:

sudo apt install --reinstall xserver-xorg

Oder, wenn ihr GNOME/KDE nutzt:

sudo apt install --reinstall gnome-shell
# oder
sudo apt install --reinstall kde-full

Fazit

Das Upgrade von Bookworm auf Trixie ist ein geradliniger Prozess, wenn ihr die Repositories korrekt austauscht. Mit ein paar Terminal-Befehlen und etwas Geduld ist das System schnell auf dem neuesten Stand. Die fehlende GUI ist kein Hindernis – im Gegenteil: Ihr habt volle Kontrolle über den Prozess und könnt jederzeit sehen, was passiert.

Viel Erfolg beim Upgrade!

The post Debian 12 Bookworm auf Trixie 13 upgraden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Ihr könnt die entsprechenden Schritte je nach eurer aktuellen Mint-Version und Anforderung befolgen.

Der Leitfaden wurde mit den Schritten zum Upgrade auf Linux Mint 22 von Mint 21.3 erstellt. Linux Mint hat ein GUI-Programm zum Upgrade auf die neueste Version.

Die gleichen Schritte gelten im übrigen für Benutzer, die von Mint 20.3 auf Mint 21 upgraden möchten (welches bis 2025 unterstützt wird).

Das solltet ihr vor dem Upgrade auf Linux Mint 22 wissen

Bevor ihr zu Linux Mint 22 upgraded, solltet ihr Folgendes beachten:

• Benötigt ihr das Upgrade wirklich? Linux Mint 21.x wird noch bis 2027 unterstützt.
• Ihr benötigt eine gute Internetverbindung, um Updates von über 1 GB herunterzuladen.
• Das Upgrade kann basierend auf eurer Internetgeschwindigkeit einige Stunden dauern. Ihr müsst geduldig sein.
• Es ist eine gute Idee, einen Live-USB von Linux Mint 22 zu erstellen und ihn in einer Live-Sitzung auszuprobieren, um zu sehen, ob er mit eurer Hardware kompatibel ist und alles bestens funktioniert. In der Regel wird ältere Hardware mit neueren Mint Versionen noch besser unterstützt.
• Obwohl Upgrades meist sicher sind, sind sie nicht immer zu 100% fehlerfrei. Ihr solltet System-Snapshots und angemessene Sicherungen haben.
• Ihr könnt nur von Linux Mint 21.3 Cinnamon, Xfce und MATE zu Linux Mint 22 upgraden. Überprüft zuerst eure Linux-Mint-Version. Wenn ihr Linux Mint 21.2 oder 21.1 verwendet, müsst ihr zuerst vom Update Manager auf 21.3 upgraden. Wenn ihr Linux Mint 20 verwendet, rate ich euch, eine Neuinstallation durchzuführen, anstatt auf mehrere Mint-Versionen zu upgraden.

Sobald ihr wisst, was ihr tun werdet, schauen wir uns an, wie ihr zu Linux Mint 22 upgraded.

Upgrade auf Linux Mint 22 von 21.3

Überprüft eure Linux-Mint-Version und stellt sicher, dass ihr Mint 21.3 verwendet.

lsb_release -a

Ihr könnt nicht von Mint 21.1 oder 21.2 zu Mint 22 upgraden. Stellt sicher, dass ihr das System auf Mint 21.3 aktualisiert habt, bevor ihr euch an das Upgrade macht.

Schritt 1: Aktualisiert euer System durch Installation aller verfügbaren Updates

Startet als erstes den Update Manager mit Menu → sucht nach Update → geht auf die Aktualisierungsverwaltung.

Überprüft, ob Package-Updates verfügbar sind. Wenn ja, installiert zuerst alle Software-Updates.

Die Meldung „Euer System ist aktuell" wird im Software-Manager angezeigt.

Ihr könnt auch diesen Befehl im Terminal für diesen Schritt verwenden:

sudo apt update && sudo apt upgrade -y

Führt auf jeden Fall ein Neustart des System durchs sobald ihr alles geupdated habt.

Schritt 2: Erstellt eine Sicherung eurer Dateien auf einer externen Festplatte (Optional, aber empfohlen)

Timeshift ist ein gutes Programm zum Erstellen von System-Snapshots, aber es ist nicht das unkomplizierteste Programm für eure Dokumente, Bilder und andere persönliche Dateien, wenn man mal schnell ein Backup durchführen will. Ich rate euch, eine Timeshift Sicherung, oder eine manuelle Sicherung auf einer externen Festplatte zu erstellen. Dies dient einfach der Datensicherheit.

Wenn ich sage, eine Sicherung auf einer externen Festplatte zu erstellen, meine ich einfach, eure Ordner Bilder, Dokumente, Downloads und Videos auf einen externen USB-Stick zu kopieren und einzufügen.

Wenn ihr keine Festplatte dieser Größe habt, kopiert zumindest die wichtigsten Dateien, auf die ihr nicht verzichten könnt.

Schritt 3: Installiert das Upgrade-Programm

Jetzt, da euer System aktualisiert ist, seid ihr bereit, zu Linux Mint 22 zu upgraden. Das Linux-Mint-Team stellt ein GUI-Programm namens mintupgrade zum Upgrade von Linux Mint 21.3 auf Linux Mint 22 zur Verfügung.

Ihr könnt dieses Programm mit dem folgenden Befehl installieren:

sudo apt install mintupgrade

Schritt 4: Startet das GUI-Programm vom Terminal

Ihr könnt das neue GUI-Programm nicht im App-Menü aufgelistet finden. Zum Starten müsst ihr den folgenden Befehl im Terminal eingeben:

sudo mintupgrade

Dieses einfache, aber umfassende Programm führt euch durch den Upgrade-Prozess.

Es wird euch fragen, ob es eine Reihe von Tests durchführen darf, um euren Computer auf ein Upgrade vorzubereiten.

Eine Reihe von Tests wird durchgeführt, um den Computer auf das Upgrade vorzubereiten.

Nach diesen Anfangstests werden euch Timeshift-Sicherungen angefordert. Wenn ihr bereits eine Sicherung erstellt habt, seid ihr bereit.

Klickt auf Beheben, um ein aktuelles Timeshift Backup anzulegen.

Wenn ihr das Upgrade auf einer VM oder ähnlichem testet, benötigt ihr möglicherweise nicht den Timeshift-Snapshot. Klickt in diesem Fall auf das Hamburger-Menü oben rechts und wählt Einstellungen.

Im den Einstellungen der Aktualisierung oben rechts im Burgermenu, könnt ihr die Anforderung für Timeshift-Sicherung deaktivieren.

In den meisten Fällen solltet ihr das nicht tun. Eine aktive Sicherung ist während solcher Versionsupgrades notwendig.

Die meissten PPAs sind bereits für Ubuntu 24.04, und damit für Mint 22, verfügbar. Aber wenn ein PPA oder Repository für die neue Version nicht verfügbar ist, könnte dies den Upgrade-Prozess mit fehlerhaften Abhängigkeiten beeinflussen. Dies wird euch im Upgrade-Programm mitgeteilt. Dies wird aber zum heutigen Zeitpunkt eher weniger der Fall sein, da Linux Mint 22 bereits einige Zeit verfügbar ist. Trotzdem gehen wir auf die Fehlerbehebung während des Update Prozesses ein!

Hier zum Beispiel ist das Vim-PPA ist für Mint 22 nicht verfügbar

In diesem Beispiel habe ich die neueste Version von Vim über PPA verwendet. Dasselbe PPA wird nur bis Ubuntu Jammy Jellyfish (22.04) unterstützt, daher der Fehler, da Linux Mint 22 auf Noble Numbat (24.04) basiert.

Klickt auf Korrigieren und euch wird die Möglichkeit gegeben, die PPAs über Softwarequellen im Upgrade-Programm zu deaktivieren.

Da das PPA deaktiviert ist, wird das Paket „fremd", da die verfügbare Version aus dem Repository nicht mit den Versionen aus den Mint-Repositories übereinstimmt. Daher müsst ihr die Pakete auf eine Version herabstufen, die im Repository verfügbar ist. Klickt hier einfach auf Reparieren.

Jetzt beginnt Phase zwei. Hier werden nach einem Klick auf OK einige Tests durchgeführt und Pakete heruntergeladen.

Das Upgrade-Programm listet nun die Änderungen auf, die durchgeführt werden müssen.

Änderungen, die durchgeführt werden müssen, sind aufgelistet.

Nach Bestätigung mit OK wird das Programm mit dem Download der Pakete beginnen.

Phase drei: nach einem Klick auf OK wird mit dem Upgrade der Pakete begonnen.

Wenn ihr auf OK klickt, beginnt also das eigentliche Upgrade der Pakete.

Das System wird aktualisiert. Der Prozess dauert einige Zeit.

In einigen Fällen müssen während der Installation weitere Pakete herabgestuft werden, um Konflikte zu vermeiden. Klickt auf Beheben, um fortzufahren.

Mehr Pakete müssen herabgestuft werden, um den Upgrade-Prozess fortzusetzen:

Dies entfernt die weiteren inkompatiblen Pakete.

Nach Abschluss geht ihr zur Finalisierungsphase über.

Danach erhaltet ihr eine Benachrichtigung, dass das Upgrade abgeschlossen wurde.

Schließt das Upgrade-Programm und startet euer System neu, damit das Update wirksam wird.

Nach dem Neustart seid ihr im neuen Linux Mint 22 🎉

Seid ihr auf Linux Mint 22 umgestiegen?

Das Upgrade auf Mint 22 ist genauso einfach wie auf die vorherige Version. Und es wird nur noch besser.

Wenn ihr euch immer noch nicht entscheiden könnt, möchtet ihr vielleicht unsere Linux-Mint-22-Rezension vor dem Upgrade lesen.

Ich hoffe, ihr findet das Anleitung hilfreich. Seid ihr auf Linux Mint 21 umgestiegen oder habt ihr euch für eine Neuinstallation entschieden?

Falls ihr auf Probleme stoßt oder weitere Hilfe zum Upgrade-Prozess benötigt, könnt ihr gerne eine Frage im Kommentarbereich stellen.

Credits: itsfoss.com. Die Bilder mit dem schwarzen Hintergrund stammen von itsfoss.com da bei mir keine Fehler beim Updateprozess aufgetreten sind. Der Vollständigkeit halber, wollte ich diese Schritte aber inkludieren.

The post So upgradet ihr auf Linux Mint 22 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

AdventureLog ist eine moderne Plattform, um besuchte Orte, geplante Reisen und persönliche Erlebnisse übersichtlich zu organisieren. Alles passiert auf unserer eigenen Infrastruktur und unterliegt denselben Datenschutz-Grundsätzen wie unsere übrigen Dienste.

✈️ Was kannst du mit AdventureLog machen?

• 📍 Reisen und Orte dokumentieren
  Halte fest, wo du warst, wann du dort warst und was du erlebt hast – inklusive Notizen, Bewertungen und persönlichen Eindrücken.
• 🗺️ Interaktive Kartenansicht
  Deine Abenteuer werden übersichtlich auf einer Weltkarte dargestellt – ideal, um vergangene Reisen zu visualisieren oder zukünftige Ziele zu planen.
• 📅 Zukünftige Trips planen
  Plane Reisen im Voraus, erstelle Itineraries, füge Aktivitäten hinzu und behalte den Überblick über anstehende Abenteuer.
• 🧭 Chronologische Übersicht
  Alle Reisen werden zeitlich geordnet angezeigt – perfekt als persönliches Reisetagebuch.
• 🔗 Teilen, wenn du willst
  Einzelne Reisen oder Ansichten können optional per Link geteilt werden – komplett freiwillig und kontrolliert.

🔐 Fokus auf Datenschutz

AdventureLog kommt ohne externe Tracker, ohne Werbenetzwerke und ohne Profilbildung aus. Deine Daten bleiben bei uns und werden nicht für Analyse- oder Marketingzwecke missbraucht.
Du nutzt einen vollwertigen Reise-Service, ohne dich dafür gläsern machen zu müssen.

🌱 Für wen ist AdventureLog gedacht?

• Für Reisende, die ihre Erlebnisse digital festhalten möchten
• Für Nutzer, die ihre Reisen planen wollen, ohne Google-Dienste zu nutzen
• Für alle, die Wert auf Privatsphäre, Kontrolle und Transparenz legen

AdventureLog ergänzt unser bestehendes Angebot an freien und datenschutzfreundlichen Diensten und bietet dir eine echte Alternative zu kommerziellen Reise-Apps.

Zu AdventureLog gehts hier!

The post AdventureLog – Reisen & Erlebnisse appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Ratgeber erfahrt ihr, worauf es beim Kauf eines Linux Laptops ankommt, welche Vorteile euch erwarten und warum ein vorkonfiguriertes Gerät oft die bessere Wahl ist.

Warum einen Linux Laptop kaufen

Linux hat sich längst von der "Nerd-Distribution" zum ausgereiften Desktop-System entwickelt. Die Vorteile liegen auf der Hand:

Performance und Ressourcen: Linux läuft auch auf älterer Hardware flüssig. Wo Windows 11 mindestens 8 GB RAM verlangt, kommt Linux oft mit der Hälfte aus. Das bedeutet längere Akkulaufzeit und schnellere Reaktionszeiten – gerade bei Laptops ein entscheidender Vorteil.

Privatsphäre und Kontrolle: Keine Telemetrie, keine Zwangs-Updates, keine versteckten Datensammlungen. Ihr entscheidet, was auf eurem System läuft und welche Daten ihr teilt.

Kosten: Die meisten Linux-Distributionen sind kostenlos. Bei einem neuen Laptop spart ihr euch die Windows-Lizenz, die oft 100-150 CHF kostet. Auch Software ist meist Open Source und gratis verfügbar.

Noch unsicher, ob Linux das Richtige für euch ist? Hier erfahrt ihr mehr über die Gründe für den Umstieg.

Worauf beim Kauf eines Linux Laptops achten

Hardware-Kompatibilität ist entscheidend

Nicht jede Hardware funktioniert out-of-the-box mit Linux. Besonders kritisch sind:

• WLAN-Chips: Broadcom oder Mediatek bereiten oft Probleme, Intel und Atheros laufen meist problemlos
• Grafikkarten: NVIDIA benötigt proprietäre Treiber, AMD und Intel funktionieren nativ besser
• Touchpads und Fingerprint-Sensoren: Moderne Synaptics-Touchpads sind gut unterstützt, biometrische Sensoren oft nicht, Linux Mint 23 soll das aber ändern!

Mehr Details zur Hardware-Kompatibilität findet ihr in unserem ausführlichen Artikel zur benötigten Hardware.

Die richtige Distribution wählen

Mint, Ubuntu, Fedora, Mint, Pop!_OS – die Auswahl ist riesig. Für Einsteiger eignen sich besonders:

• Ubuntu/Linux Mint: Große Community, viele Tutorials, stabile Basis
• Fedora: Modern, aktuelle Software, guter Kompromiss
• Pop!_OS: Speziell für Laptops optimiert, NVIDIA-Support integriert

Nicht sicher, welches Linux zu euch passt? Nutzt unseren Linux Finder – ein interaktives Quiz, das basierend auf euren Anforderungen die perfekte Distribution empfiehlt.

Einen Überblick über alle gängigen Systeme bekommt ihr in unserem Betriebssystem-Vergleich.

ThinkPads: Die Klassiker für Linux-User

Wenn von Linux-Laptops die Rede ist, fallen fast immer ThinkPads. Die Lenovo-Serie hat sich über Jahrzehnte einen legendären Ruf in der Linux-Community erarbeitet – aus gutem Grund.

Warum ThinkPads so beliebt sind:

Hervorragende Hardware-Kompatibilität: Lenovo testet ThinkPads aktiv mit Linux-Distributionen. Treiber funktionieren out-of-the-box, keine Bastelei mit WLAN-Chips oder Touchpads.

Robuste Bauweise: ThinkPads sind für den Business-Einsatz konzipiert. Das bedeutet solide Verarbeitung, gute Tastatur und Langlebigkeit – wichtig, wenn ihr das Gerät täglich nutzt.

Riesige Community: Für nahezu jedes ThinkPad-Modell findet ihr Online-Dokumentation, Tipps und Support von anderen Linux-Usern.

Bei yourdevice.ch führen wir die ThinkPad E-Serie – solide Mittelklasse-Modelle, die das Beste aus beiden Welten bieten: ThinkPad-Qualität ohne Premium-Preis. Hier geht's zu unseren ThinkPad E14 und E16 Modellen.

Support und Garantie in der Schweiz

Ein oft unterschätzter Punkt: Kauft ihr einen Linux Laptop in der Schweiz, habt ihr lokalen Support und Garantie nach Schweizer Recht. Bei Import-Geräten aus dem Ausland müsst ihr bei Problemen oft aufwendig zurückschicken. Ausserdem verweigern Hersteller häufig den Support, sollte ein neueres Gerät defekt gehen, und ihr hattet darauf Linux installiert da das Gerät dann nicht mehr dem original Zustand entspricht. Bei uns ist Linux Originalzustand!

Vorkonfiguriert kaufen vs. selbst installieren

Technisch versierte User können natürlich jeden Laptop kaufen und Linux selbst installieren. Aber ist das wirklich die beste Lösung?

Vorteile vorkonfigurierter Linux Laptops:

Zeitersparnis: Die Installation dauert zwar nur 30-60 Minuten, aber Treiber konfigurieren, Updates einspielen, System absichern und Software installieren kostet schnell mehrere Stunden. Bei einem vorkonfigurierten System ist alles fertig eingerichtet.

Funktionierende Treiber: Alle Hardware-Komponenten sind getestet und funktionieren garantiert. Keine bösen Überraschungen mit nicht funktionierendem WLAN oder Touchpad.

Professionelle Einrichtung: Das System ist bereits mit sinnvollen Einstellungen konfiguriert, Updates sind richtig eingerichtet, und grundlegende Sicherheitsmaßnahmen sind implementiert.

Support bei Problemen: Wenn doch mal etwas nicht funktioniert, habt ihr einen Ansprechpartner, der das System kennt und helfen kann.

Linux vorher ausprobieren

Wer möchte, kann Linux über eine virtuelle Maschine vorher schnell und einfach ausprobieren. Das geht zum Beispiel über eine virtuelle Maschine, oder über die Installation von Linux auf einer externen SSD. So kann man sich vorher schon ein Bild machen, welches Linux am besten zu einem passt.

Linux im Alltag: Keine Kompromisse nötig

"Aber funktioniert mein Scanner?" – "Kann ich Office-Dokumente bearbeiten?" Ja und ja!

Office und Produktivität

Office auf Linux ist längst kein Problem mehr. LibreOffice bietet volle Kompatibilität mit Microsoft-Formaten. Für cloudbasiertes Arbeiten funktionieren Google Docs und Microsoft 365 im Browser einwandfrei.

E-Mail-Programme wie Thunderbird stehen Windows in nichts nach. Wer mehr Privatsphäre will, findet bei uns auch Matrix-basierte Chat-Lösungen.

Hardware-Peripherie

Scanner funktionieren unter Linux meist besser als unter Windows – dank des SANE-Projekts werden tausende Modelle unterstützt. Drucker, Webcams, externe Festplatten: Alles läuft in der Regel problemlos.

Software-Alternativen

Für fast jedes Windows-Programm gibt es eine Linux-Alternative. Unsere Übersicht zeigt euch die besten Alternativen.

Ist Linux kompliziert?

Kurze Antwort: Nein. Ihr müsst keine Terminal-Kenntnisse besitzen, um Linux zu nutzen. Moderne Distributionen sind so bedienbar wie Windows oder macOS.

Für den vollständigen Überblick: Unser Overall-Leitfaden für den Umstieg begleitet euch Schritt für Schritt.

Linux Laptops kaufen bei yourdevice.ch

Seit Jahren bieten wir bei yourdevice.ch vorkonfigurierte Linux Laptops in der Schweiz an. Aber wir sind mehr als nur ein Shop.

Freie Betriebssystem-Wahl

Ihr entscheidet, welches Linux auf eurem Laptop läuft. Ubuntu, Fedora, Mint, Pop!_OS – oder nutzt unseren Linux Finder, um die perfekte Distribution zu finden. Wir installieren und konfigurieren das System nach euren Wünschen.

Umfangreiche Knowledgebase

Mit über 340 Artikeln zu Linux, Netzwerk, Bitcoin und mehr bieten wir eine der umfassendsten deutschsprachigen Linux-Ressourcen. Egal ob Antiviren-Programme, Festplatten-Verschlüsselung oder alltägliche Fragen – ihr findet Antworten.

Exklusive Open-Source-Services

Als Kunde bei yourdevice.ch erhaltet ihr kostenlosen Zugang zu einer Vielzahl von Open-Source-Services:

Cloud & Zusammenarbeit:

• Nextcloud (10GB gratis für Kunden) – eure eigene Cloud, keine Google Drive Abhängigkeit
• Matrix Chatserver – verschlüsselte Kommunikation, WhatsApp-Alternative
• Jitsi Meet – Videokonferenzen ohne Zoom oder Teams
• Element Web – moderner Matrix-Client im Browser

Privatsphäre & Sicherheit:

• Vaultwarden – Passwort-Manager (Bitwarden-kompatibel)
• Trash Mail Service – Wegwerf-E-Mails für mehr Privatsphäre
• VPN-freundliche DNS-Server – keine Zensur, keine Tracking
• Clientseitige Datei-Verschlüsselung – eure Daten, eure Kontrolle

Kommunikation & Alternativen:

• WhatsApp Proxy Server – Zugriff in zensierten Ländern
• Alternative IMDB-Frontends – Filminfos ohne Werbung
• Multi-Translator – Übersetzungen ohne Big Tech

Tools & Entwicklung:

• Bitcoin Mining Pool – für die Krypto-Community
• Private Electrum Server – Bitcoin-Wallet-Backend
• Event Planner – gemeinsam Events organisieren
• Linkwarden – Bookmark-Manager
• Find My Device – Geräteortung mit Open Source

Alle Services sind für Kunden kostenlos und direkt über euer Konto von yourdevice.ch nutzbar und werden aktiv gewartet. Keine Werbung, keine Datensammlung, nur funktionierende Tools für euren Alltag.

Lokaler Support aus der Schweiz

Probleme? Fragen? Wir sprechen Deutsch und sind für euch da. Keine Hotline in Indien, kein Ticket-System, das tagelang dauert – echte Menschen mit Linux-Expertise helfen euch weiter.

Dualboot Systeme mit Windows

Seit ihr euch noch nicht ganz sicher bezüglich des Umstiegs und benötigt Windows parallel zur Linux? Auch das bieten wir an, bei Bedarf installieren wir Linux parallel zu Windows, so kann man für das Was laufen muss, Windows verwenden, und für den Umstieg und das kennen lernen Linux benutzen.

Bereit für den Umstieg?

Linux Laptops kaufen in der Schweiz war noch nie so einfach. Kombiniert Hardware, die funktioniert, mit einem Betriebssystem, das euch gehört, und einem Service-Paket, das euch unabhängig macht.

Entdeckt jetzt unsere Linux-Laptop-Auswahl oder nutzt unseren Linux Finder, um die perfekte Distribution zu finden.

Fragen? Schreibt uns – wir beraten euch gerne bei der Auswahl des richtigen Systems für eure Bedürfnisse.

The post Linux Laptop kaufen in der Schweiz: Kaufratgeber 2026 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was bedeutet das konkret für euch? Ihr glaubt, eure Windows-Festplatte sei verschlüsselt und sicher. Aber wenn Microsoft die Schlüssel in der Cloud speichert, können US-Behörden mit einem Durchsuchungsbefehl darauf zugreifen. Eure Verschlüsselung ist nur so sicher, wie das Unternehmen, das die Schlüssel verwaltet.

Microsoft bestätigte gegenüber Forbes, dass das Unternehmen etwa 20 solcher Anfragen pro Jahr erhält – und sie erfüllt, wenn eine gültige gerichtliche Anordnung vorliegt. Das Problem: Windows 11 sichert diese Wiederherstellungsschlüssel standardmäßig in der Microsoft Cloud, sobald ihr euch mit einem Microsoft-Konto anmeldet. Die meisten Nutzer wissen nicht einmal, dass dies passiert.

Das ist kein Einzelfall. Es ist die konkrete Realität des CLOUD Act.

Was ist der CLOUD Act?

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act) von 2018 ist ein US-Gesetz mit einer einfachen, aber weitreichenden Regelung: US-Behörden können von US-Unternehmen die Herausgabe von Daten verlangen – egal wo auf der Welt die Server stehen.

Die Kernpunkte, die ihr wissen müsst:

1. Der Serverstandort ist irrelevant
Eure Daten können in einem Rechenzentrum in Frankfurt, Amsterdam oder Zürich liegen – wenn das Unternehmen unter US-Kontrolle steht, kann das FBI mit einem Durchsuchungsbefehl darauf zugreifen.

2. Ihr werdet nicht informiert
Die Betroffenen erfahren in der Regel nie, dass ihre Daten abgerufen wurden. US-Behörden können "Gag Orders" (Schweigeanordnungen) verhängen, die es Unternehmen verbieten, ihre Kunden zu informieren.

3. Fast alle großen Tech-Konzerne sind betroffen
Microsoft, Google, Amazon, Apple, Meta (Facebook), Dropbox, Slack, Zoom – sie alle unterliegen dem CLOUD Act, weil sie US-Unternehmen sind.

4. Auch Tochtergesellschaften bieten keinen Schutz
Microsoft Deutschland, Google Switzerland, Amazon Luxembourg – die US-Muttergesellschaft kann angewiesen werden, ihre Tochter zur Datenherausgabe zu zwingen.

Warum das für euch als Privatperson wichtig ist

Viele denken: "Ich habe nichts zu verbergen, warum sollte mich das interessieren?" Hier sind konkrete Gründe:

Eure privaten Fotos, E-Mails und Dokumente
Wenn ihr Microsoft OneDrive, Google Drive oder Dropbox nutzt, liegen eure Familienfotos, persönlichen E-Mails und privaten Dokumente auf US-Servern. US-Behörden können darauf zugreifen – ohne dass ihr es je erfahrt.

Eure Gesundheitsdaten
Nutzt ihr eine Fitness-App eines US-Anbieters? Synchronisiert ihr Gesundheitsdaten in die Cloud? Diese Daten können abgerufen werden.

Eure Kommunikation
WhatsApp (gehört zu Meta/Facebook), Gmail, Outlook.com – alles US-Dienste. Eure Kommunikation kann durchsucht werden.

Geschäftliche Dokumente
Selbstständige und kleine Unternehmen: Vertrauliche Verträge, Kundendaten, Geschäftsgeheimnisse – alles potenziell zugänglich für US-Behörden.

Die Illusion der "EU-Cloud"

Microsoft, Google und Amazon bewerben ihre "EU-Rechenzentren" als sichere Lösung. Das ist Marketing, keine Datenschutzgarantie.

Eure Daten können in Frankfurt auf deutschen Servern liegen – wenn Microsoft Azure sie verwaltet, unterliegen sie trotzdem dem CLOUD Act. Die Gerichtsbarkeit folgt dem Eigentümer, nicht dem Serverstandort.

Selbst wenn ein US-Konzern eine europäische Tochtergesellschaft gründet, die formal die Daten verwaltet: Die US-Muttergesellschaft kann angewiesen werden, die Tochter zur Herausgabe zu zwingen.

Warum Verschlüsselung allein nicht hilft

"Aber meine Daten sind doch verschlüsselt!" höre ich oft. Das Problem: Wer kontrolliert die Schlüssel?

Der BitLocker-Fall zeigt es deutlich: Wenn Microsoft eure Verschlüsselungsschlüssel in der Cloud speichert, kann das Unternehmen gezwungen werden, sie herauszugeben. Eure Verschlüsselung wird wertlos.

Was ihr über Verschlüsselung wissen müsst:

Client-seitige Verschlüsselung: Nur ihr habt die Schlüssel, der Anbieter sieht nur verschlüsselte Daten.
→ Gut: Signal, Tresorit, Proton Drive
→ Schlecht: Standard OneDrive, Google Drive, Dropbox

Server-seitige Verschlüsselung: Der Anbieter verschlüsselt die Daten, hat aber selbst die Schlüssel.
→ Das ist wie ein Tresor, zu dem auch die Bank den Schlüssel hat.

Zero-Knowledge-Architektur: Der Anbieter kann technisch nicht auf eure Daten zugreifen.
→ Genau das fehlt bei Microsoft, Google, Amazon

Apple und Google bieten mittlerweile erweiterten Datenschutz mit Ende-zu-Ende-Verschlüsselung für Cloud-Backups an. Microsoft nicht. Senator Ron Wyden (USA) kritisierte: "Es ist schlicht unverantwortlich, dass Tech-Unternehmen Produkte ausliefern, die es ihnen erlauben, heimlich die Verschlüsselungsschlüssel der Nutzer herauszugeben."

Die praktische Lösung: Open Source und Selbst-Hosting

Die gute Nachricht: Ihr müsst nicht auf Komfort verzichten, um eure Privatsphäre zu schützen. Es gibt ausgereifte, quelloffene Alternativen zu allen gängigen Cloud-Diensten.

1. Linux statt Windows/macOS

Warum Linux?

• Keine Telemetrie, die heimlich Daten sendet
• kein Login oder Anmelde-Zwang
• Keine Cloud-Zwangsintegration
• Volle Kontrolle über euer System
• Keine BitLocker-Schlüssel in fremden Händen

Empfohlene Distributionen für Einsteiger:

• Linux Mint: Perfekt für Windows-Umsteiger
• Ubuntu: Große Community, viel Support
• Fedora: Modern und sicher
• Pop!_OS: Ausgezeichnet für Nvidia-Grafikkarten

Verschlüsselung unter Linux:
LUKS (Linux Unified Key Setup) verschlüsselt eure Festplatte – und ihr verwaltet die Schlüssel. Keine Cloud-Uploads, keine Hintertüren.

2. Nextcloud statt OneDrive/Google Drive

Nextcloud ist die Open-Source-Alternative zu Microsoft 365 und Google Workspace. Alles, was diese Dienste können, kann Nextcloud auch – aber unter eurer Kontrolle.

Features:

• Datei-Synchronisation (wie Dropbox)
• Kalender und Kontakte (CalDAV/CardDAV)
• Office-Dokumente (Collabora Online, ONLYOFFICE)
• E-Mail-Integration
• Videokonferenzen (Nextcloud Talk)
• Aufgabenverwaltung
• Passwort-Manager
• Notizen
• Fotogalerien mit automatischem Upload vom Smartphone

Drei Möglichkeiten, Nextcloud zu nutzen:

Option A: Gemietetes Hosting in Europa
Wir bieten managed, aber auch fertige Nextcloud-Instanzen:

• Einfach, wartungsfrei
• DSGVO-konform
• Rechenzentren in Deutschland, Spanien, Frankreich oder je nach Standort von IONIS
• Ab ca. 16CHF pro Monat

Option B: Eigener Server zuhause (Self-Hosting)
Eine Synology oder UGREEN NAS bei euch im Büro/Zuhause:

• Einmalige Hardware-Kosten (ab ca. 400-800CHF)
• Keine monatlichen Gebühren
• Physische Kontrolle über die Hardware
• Synology DiskStation bietet diverse Apps für Fotos, Datensicherungen und Spiegelungen
• UGREEN NASync läuft perfekt mit Docker/Nextcloud

Option C: Selber Virtual Private Server (VPS) mieten
Ein gemieteter Server bei einem europäischen Hoster:

• Volle Kontrolle
• Root-Zugriff
• Selbst installieren und konfigurieren
• Anbieter: Hetzner, netcup, Contabo, IONOS (alle Deutschland)
• Ab ca. 5€/Monat

3. Freie Protokolle: CalDAV, CardDAV, WebDAV

Einer der größten Vorteile von Open Source: Keine Vendor-Lock-ins durch proprietäre Protokolle.

CalDAV (Kalender): Synchronisiert eure Termine zwischen allen Geräten
CardDAV (Kontakte): Synchronisiert Adressbücher
WebDAV (Dateien): Standard-Protokoll für Datei-Synchronisation

Diese Protokolle funktionieren mit jeder kompatiblen Software:

• Thunderbird (Desktop)
• Evolution (Linux)
• Apple Kalender & Kontakte (iOS/macOS)
• DAVx⁵ (Android)
• Viele weitere

Ihr seid nicht an einen Anbieter gebunden. Wechsel sind einfach – kopiert einfach eure Daten auf einen neuen Server.

Praktische Artikel zum Thema DAV:

https://yourdevice.ch/nextcloud-direkt-via-webdav-in-linux-und-windows-einbinden/

https://yourdevice.ch/thunderbird-kalender-mit-nextcloud-caldav-verbinden/

https://yourdevice.ch/iphone-kalender-auf-android-oder-in-die-nextcloud-uebertragen/

https://yourdevice.ch/kontakte-und-sms-auf-ein-custom-rom-uebertragenkontakte-und-sms-von-android-oder-iphone-auf-custom-rom-uebertragen/

https://yourdevice.ch/kontakte-synchronisieren-mit-nextcloud-android-und-thunderbird/

https://yourdevice.ch/nextcloud-direkt-in-android-einbinden/

https://yourdevice.ch/nextcloud-kalender-mit-android-synchronisieren/

4. E-Mail: Europäische Provider

Statt Gmail/Outlook.com:

• Mailbox.org (Deutschland) – DSGVO-konform, grüner Strom
• Proton Mail (Schweiz) – Ende-zu-Ende-verschlüsselt
• Tutanota (Deutschland) – Zero-Knowledge-Verschlüsselung
• Posteo (Deutschland) – Datenschutz-fokussiert

Ausführlicher Artikel zum Thema:

Alle bieten:

• IMAP/SMTP (Standard-Protokolle)
• CalDAV/CardDAV
• Verschlüsselung
• Keine Werbung
• Kosten: 1-5€ pro Monat

5. Weitere Alternativen

Statt Google Docs:

• Collabora Online (mit Nextcloud)
• ONLYOFFICE (mit Nextcloud)
• LibreOffice (Desktop)

Statt Dropbox:

• Nextcloud (siehe oben)
• Synology Cloud Station
• Seafile

Statt Zoom/Teams:

• Jitsi Meet (Open Source, selbst-hostbar)
• BigBlueButton (ideal für Bildung)
• Nextcloud Talk

Statt Google Analytics:

• Matomo (selbst-hostbar)
• Plausible (Privacy-first, EU-hosted)
• Fathom Analytics

Statt 1Password/LastPass:

• Bitwarden (Open Source, selbst-hostbar)
• KeePassXC (lokal, keine Cloud)
• Vaultwarden (Bitwarden-kompatibler Server)

Schritt-für-Schritt: So steigt ihr aus

Woche 1: Bestandsaufnahme

• Welche Cloud-Dienste nutzt ihr?
• Wo liegen eure wichtigsten Daten?
• Welche Apps synchronisieren in US-Clouds?

Woche 2: Nextcloud einrichten

• Entweder bei einem EU-Hoster anmelden
• Oder eigene NAS/Server aufsetzen
• Nextcloud-Apps auf Smartphone installieren

Woche 3: Daten migrieren

• Fotos aus Google Photos/OneDrive herunterladen
• Dokumente nach Nextcloud verschieben
• Kalender/Kontakte exportieren und importieren

Woche 4: Umstellung abschließen

• E-Mail-Account bei europäischem Provider
• Cloud-Syncs der alten Anbieter deaktivieren
• Alte Accounts kündigen

Was ist mit Unternehmen

Für Firmen gelten besondere Anforderungen, aber die Lösungen sind ähnlich:

• Nextcloud auf einem eigenen Server oder bei EU-Hoster
• Synology mit mehreren DiskBays für Datensicherungen im RAID1 oder 5 oder QNAP/Ugreen NAS im Büro
• Linux-Workstations (Ubuntu/Fedora)
• evt dedizierter Mailserver mit Mailcow, oder Mailhoster bei einem Schweizer Unternehmen wie Informaniak

Rechtliche Absicherung:

• Transfer Impact Assessments durchführen
• Auftragsverarbeitungsverträge (AVV) mit EU-Providern
• Dokumentation der Datenflüsse
• Im Zweifelsfall: Datenschutzbeauftragten konsultieren

Häufige Einwände – und warum sie nicht stimmen

"Ich habe nichts zu verbergen"
→ Würdet ihr euer Tagebuch, eure Bankdaten und eure Fotos einem Fremden auf der Straße geben? Privatsphäre ist ein Grundrecht, kein Privileg für "Verdächtige".

"Das ist mir zu kompliziert"
→ Nextcloud ist genauso einfach wie Dropbox. Drag & Drop, fertig. In den meissten Fällen gibt es die Nextcloud bereits fertig eingerichtet. Wer selber installieren will, nutzt AIO-Docker Setups

"Ich brauche Microsoft Office für die Arbeit"
→ LibreOffice und ONLYOFFICE sind mit allen Office-Formaten kompatibel. Für die meisten Nutzer gibt es keinen funktionalen Unterschied.

"Aber alle anderen nutzen WhatsApp/Gmail"
→ Das ist keine technische, sondern eine soziale Frage. Je mehr Leute wechseln, desto normaler wird es. Seid Vorbild. Nutzt andere Messenger, zeigt den Leuten wie einfach es ist, Signal, oder Element zu verwenden.

"Das ist teurer als die kostenlosen Google-Dienste"
→ Kostenlos bedeutet: Ihr seid das Produkt. Eure Daten werden analysiert, für Werbung genutzt und – wie wir wissen – an Behörden weitergegeben. 10CHF/Monat für echte Privatsphäre sind ein Schnäppchen.

"Was ist, wenn meine NAS kaputt geht?"
→ Backups! Synology bietet Cloud-Backup zu anderen Synology-NAS, oder ihr nutzt einen EU-Backup-Dienst z.B bei Hetnzer's Storage Box. Redundanz ist bei jeder Lösung wichtig – auch Google Drive kann ausfallen.

Fazit: Digitale Souveränität ist möglich

Der CLOUD Act zeigt: Solange US-Unternehmen eure Daten kontrollieren, habt ihr keine Kontrolle. Nicht über die Sicherheit, nicht über den Zugriff, nicht über eure Privatsphäre.

Die Lösung ist nicht kompliziert:

1. Linux statt Windows – volle Systemkontrolle
2. Nextcloud statt OneDrive/Google Drive – eure Cloud, eure Regeln
3. Eigene Hardware (NAS) oder Hosting in der Schweiz oder in der EU bei nicht amerikanischen Unternehmen – physische oder rechtliche Kontrolle
4. Offene Protokolle (CalDAV, WebDAV) – keine Abhängigkeit von einzelnen Anbietern
5. Europäische E-Mail-Provider – DSGVO-konform, keine US-Zugriffe

Der Fall Microsoft/BitLocker/FBI ist nur das jüngste Beispiel. Es wird nicht das letzte sein. Solange ihr US-Dienste nutzt, gebt ihr die Kontrolle ab – freiwillig oder nicht.

Die Technologie für echte digitale Souveränität existiert bereits. Ihr müsst sie nur nutzen.

Jeder Server, den ihr selbst betreibt, jede Nextcloud-Instanz in einem schweizer oder europäischen Rechenzentrum, jeder Wechsel zu Open Source ist ein Schritt weg von Überwachung und hin zu echter Privatsphäre.

Fangt heute an. Eure Daten gehören euch – nicht Microsoft, nicht Google, und schon gar nicht dem FBI.

Quellen und weiterführende Links

1. BitLocker/FBI-Fall:
   • TechRepublic: "Microsoft Shared BitLocker Keys With FBI, Raising Privacy Fears"
     https://www.techrepublic.com/article/news-microsoft-bitlocker-keys-fbi-privacy/
   • Aardwolf Security: "Microsoft Hands Over BitLocker Encryption Keys to FBI"
     https://aardwolfsecurity.com/microsoft-hands-over-bitlocker-encryption-keys-to-fbi/
   • Medium (Mike Broadly): "Microsoft Gave BitLocker Encryption Keys to the FBI"
     https://medium.com/illumination/microsoft-gave-bitlocker-encryption-keys-to-the-fbi-and-most-windows-users-may-not-know-this-0f4c4e911929
2. CLOUD Act Grundlagen:
   • European Data Protection Board (EDPB): "Initial legal assessment of the impact of the US CLOUD Act"
     https://www.edpb.europa.eu/sites/default/files/files/file2/edpb_edps_joint_response_us_cloudact_annex.pdf
   • U.S. Department of Justice: "The Purpose and Impact of the CLOUD Act" (White Paper, 2019)
     https://www.justice.gov/opa/press-release/file/1153446/download
   • Wire: "CLOUD Act - What It Means for EU Data Sovereignty"
     https://wire.com/en/blog/cloud-act-eu-data-sovereignty
   • LexisNexis: "Cloud Act and GDPR: What implications for EU companies' data protection?"
     https://www.lexisnexis.com/blogs/int-legal/b/insights/posts/cloud-act-gdpr-implications
   • Exoscale: "CLOUD Act vs. GDPR: The Conflict About Data Access Explained"
     https://www.exoscale.com/blog/cloudact-vs-gdpr/
3. Schrems-Urteile:
   • Court of Justice of the European Union: "Schrems II" (Case C-311/18), 16. Juli 2020
     https://curia.europa.eu/juris/liste.jsf?num=C-311/18
   • The New Stack: "What GDPR, Schrems 2 and the End of Privacy Shield Means"
     https://thenewstack.io/what-gdpr-schrems-2-and-the-end-of-privacy-shield-means-to-your-kubernetes-based-service/
   • Anexia: "Implications of the Schrems II Judgement on Cloud Provider"
     https://anexia.com/blog/en/schrems-ii-cloud-provider/
4. Trans-Atlantic Data Privacy Framework:
   • European Commission: Implementing Decision (EU) 2023/1795
     https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj
   • IAPP: "How could Trump administration actions affect the EU-U.S. Data Privacy Framework?"
     https://iapp.org/news/a/how-could-trump-administration-actions-affect-the-eu-u-s-data-privacy-framework-
   • Taylor Wessing: "Die Zukunft des EU-U.S. Data Privacy Frameworks"
     https://www.taylorwessing.com/de/insights-and-events/insights/2025/01/eu-us-data-privacy-frameworks
   • Lewis Silkin: "Could Trump play the Trump card against the Data Protection Framework?"
     https://www.lewissilkin.com/insights/2025/03/30/could-trump-play-the-trump-card-against-the-data-protection-framework-102k26v
   • mailbox.org: "CLOUD Act: European companies must act now"
     https://mailbox.org/en/post/digital-sovereignty-in-uncertain-times
   • KPMG: "Data Privacy Framework: Datenaustausch mit den USA erneut auf dem Prüfstand"
     https://klardenker.kpmg.de/financialservices-hub/data-privacy-framework-datenaustausch-mit-den-usa-erneut-auf-dem-pruefstand/
   • American Security Project: "Tech Tensions—The Future of the U.S.-EU Data Privacy Framework"
     https://www.americansecurityproject.org/transatlantic-tech-tensions-the-future-of-the-u-s-eu-data-privacy-framework/
5. Praktische Anleitungen:
   • Nextcloud Homepage: https://nextcloud.com
   • LibreOffice: https://www.libreoffice.org
   • Linux Mint: https://linuxmint.com
   • Ubuntu: https://ubuntu.com
   • Fedora: https://fedoraproject.org
   • Pop!_OS: https://pop.system76.com
   • Mailbox.org: https://mailbox.org
   • Proton: https://proton.me
   • Tutanota: https://tutanota.com
   • Bitwarden: https://bitwarden.com
   • Jitsi Meet: https://meet.jit.si
   • Matomo: https://matomo.org
6. Europäische Hoster:
   • Hetzner (Deutschland): https://www.hetzner.com
   • netcup (Deutschland): https://www.netcup.de
   • Contabo (Deutschland): https://contabo.com
   • Infomaniak (Schweiz): https://www.infomaniak.com
   • OVHcloud (Frankreich): https://www.ovhcloud.com
   • Scaleway (Frankreich): https://www.scaleway.com

The post Der CLOUD Act: Eure Daten und die amerikanische Software appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Fall: FBI erhält Vollzugriff auf verschlüsselte Laptops

Im US-Außengebiet Guam ermittelten Bundesrichter gegen Verdächtige, die sich angeblich am Covid-Hilfsprogramm bereichert hatten. Die Beweise sollten drei Laptops liefern – verschlüsselt mit BitLocker. Statt an der Verschlüsselung zu scheitern, forderten die Ermittler per Gerichtsbeschluss die Schlüssel direkt von Microsoft an. Der Konzern lieferte bereitwillig. Pro Jahr soll es etwa 20 solcher Fälle geben – Tendenz vermutlich steigend.

Was hier so technisch klingt, ist ein fundamentaler Bruch des Verschlüsselungsversprechens: Festplattenverschlüsselung soll eure Daten vor unbefugtem Zugriff schützen. Wenn aber der Hersteller der Verschlüsselungssoftware selbst Zugang zu euren Schlüsseln hat und diese auf Anfrage herausgibt, dann ist die Verschlüsselung wertlos.

Das eigentliche Problem: Microsoft speichert eure Schlüssel standardmäßig in der Cloud

Das Kernproblem liegt in Microsofts Systemarchitektur. Bei der Installation von Windows 10 und 11 werdet ihr standardmäßig aufgefordert, euch mit einem Microsoft-Konto anzumelden. Was Microsoft euch dabei verschweigt: Euer BitLocker-Wiederherstellungsschlüssel landet automatisch und ungefragt in der Microsoft-Cloud. Unverschlüsselt. Für Microsoft – und damit für US-Behörden – jederzeit zugänglich.

Diese „Komfort-Funktion" ist standardmäßig aktiviert. Die meisten Nutzer haben keine Ahnung, dass ihre vermeintlich sichere Festplattenverschlüsselung durch diese Hintertür komplett ausgehebelt wird. Microsoft begründet dies mit der Benutzerfreundlichkeit: Wer seinen Schlüssel verliert, kann so einfacher auf seine Daten zugreifen. Die Wahrheit ist: Ihr verliert die Kontrolle über eure eigenen Daten.

Microsoft selbst räumt das Risiko in einer Stellungnahme ein: „Wenn die Wiederherstellung von Schlüsseln einfach ist, besteht auch das Risiko eines ungewollten Zugangs." Trotzdem bleibt die Cloud-Speicherung der Schlüssel der Standard. Die Verantwortung wird heuchlerisch auf euch abgewälzt: „Kunden sind in der besten Position, um zu entscheiden, wie sie ihre Schlüssel verwalten" – nur dass die meisten Kunden nicht einmal wissen, dass diese Entscheidung getroffen wird.

Massenüberwachung durch Design: Microsoft ermöglicht Behördenzugriff auf Millionen Geräte

Die Dimension dieses Problems wird deutlich, wenn man sich die Verbreitung von Windows ansieht. Hunderte Millionen Geräte weltweit nutzen BitLocker mit aktivierter Cloud-Schlüssel-Speicherung. Das bedeutet: Microsoft und damit potentiell auch US-Behörden haben theoretisch Zugang zu den Festplatten von Millionen Menschen – Privatpersonen, Unternehmen, Behörden, Journalisten, Aktivisten.

Kryptographie-Experte Matt Green von der Johns Hopkins University bringt es auf den Punkt: „Das sind private Daten auf privaten Computern und Microsoft hat die architektonische Entscheidung getroffen, einen Zugang zu diesen Daten zu haben." Green hebt hervor, dass Microsoft damit alleine steht: Apple und Google implementieren ihre Verschlüsselungssysteme ohne zentrale Zugangsmöglichkeiten.

Das FBI-Beispiel zeigt: Wenn Behörden die Möglichkeit haben, nutzen sie diese auch. Besonders problematisch: Mit den BitLocker-Schlüsseln erhalten Ermittler Zugriff auf das komplette Gerät – nicht nur auf die Daten, die für den jeweiligen Fall relevant sind. Ein digitaler Generalschlüssel für euer gesamtes digitales Leben.

NSAKEY: Microsoft und die NSA – eine lange Geschichte der Zusammenarbeit

Die aktuelle BitLocker-Kontroverse ist kein Einzelfall, sondern reiht sich in eine lange Geschichte fragwürdiger Kooperationen zwischen Microsoft und US-Geheimdiensten ein. 1999 entdeckte der Kryptographie-Experte Andrew D. Fernandes eine Variable namens „_NSAKEY" in Windows NT 4.0 – einen 1024-Bit öffentlichen Schlüssel mit direktem Bezug zur National Security Agency (NSA).

Die Entdeckung löste massive Spekulationen aus: Hatte die NSA eine Hintertür in Windows eingebaut? Microsoft dementierte vehement und behauptete, der Name stamme lediglich daher, dass die NSA die technische Prüfbehörde für US-Kryptographie-Exportkontrollen sei. Die Erklärung überzeugte Sicherheitsexperten nicht. Besonders brisant: In Windows 2000 wurde ein dritter, nicht dokumentierter Schlüssel gefunden, der laut Sicherheitsforscher Dr. Nicko van Someren „fishy" aussah.

Die Parallelen zum aktuellen BitLocker-Skandal sind offensichtlich: Damals wie heute geht es um kryptographische Schlüssel in Windows-Systemen, damals wie heute gibt es Verbindungen zu US-Geheimdiensten, und damals wie heute versucht Microsoft, die Vorwürfe herunterzuspielen.

https://en.wikipedia.org/wiki/NSAKEY

Senator Wyden: „Unverantwortlich, Produkte auszuliefern, die heimliches Ausliefern von Nutzerdaten ermöglichen"

Die politische Kritik ist eindeutig. Ron Wyden, demokratischer Senator und bekannter Datenschutzaktivist, verurteilt Microsofts Vorgehen scharf: Für Tech-Konzerne sei es unverantwortlich, Produkte auszuliefern, die das heimliche Ausliefern von Nutzerdaten ermöglichen.

Auch Windows Central bezeichnet es als „schockierend", dass Microsoft die BitLocker-Schlüssel ungesichert in Nutzerkonten hinterlegt. Nutzer würden bei der Installation aktiv dazu hingeleitet, das Schlüssel-Backup zu aktivieren – ohne über die massiven Risiken für ihre Privatsphäre aufgeklärt zu werden. Das ist keine Fahrlässigkeit, das ist System.

Apple und Google: Kein Grund zum Jubeln – auch sie kooperieren mit Behörden

Die Tech-Industrie präsentiert sich gerne als Verteidiger eurer Privatsphäre. Die Realität sieht anders aus. Zwar lieferte sich Apple 2016 einen medienwirksamen Rechtsstreit mit dem FBI um das iPhone des San Bernardino-Attentäters – doch hinter den Kulissen ist die Geschichte wesentlich schmutziger.

Was die meisten nicht wissen: Apple händigt seit Jahren bereitwillig iCloud-Backup-Daten an US-Behörden aus. Laut eigenen Transparenzberichten übergab Apple allein in der ersten Hälfte eines Jahres in 1.568 Fällen Nutzerdaten an die Regierung. Der Grund: iCloud-Backups waren bis 2022 nicht Ende-zu-Ende verschlüsselt – Apple hatte die Schlüssel und konnte auf richterliche Anordnung zugreifen.

Noch brisanter: 2018 plante Apple, iCloud-Backups endlich vollständig Ende-zu-Ende zu verschlüsseln. Nach Gesprächen mit dem FBI ließ Apple das Projekt fallen. Reuters berichtete, dass Apple "überzeugt" wurde von den Argumenten der Behörden. Die angebliche Datenschutz-Ikone knickte ein, um es sich nicht mit dem FBI zu verscherzen.

Erst Ende 2022 – vier Jahre später – führte Apple "Advanced Data Protection" ein, mit echter Ende-zu-Ende-Verschlüsselung für iCloud. Der Haken: Es ist ein Opt-In Feature. Standardmäßig landen eure iCloud-Backups weiterhin unverschlüsselt auf Apples Servern, zugänglich für Behörden mit Gerichtsbeschluss.

Google steht nicht besser da. Der Konzern baute 2009 eine Backdoor in Gmail, um Behörden bei gültigen Gerichtsbeschlüssen Zugriff zu gewähren. Diese Backdoor wurde von chinesischen Hackern ausgenutzt, um auf sensible US-Überwachungsziele zuzugreifen – ein perfektes Beispiel dafür, warum Hintertüren niemals sicher sind. Sicherheitsexperte Bruce Schneier bestätigte: "Die chinesischen Hacker nutzten genau die Backdoor, die für US-Behörden geschaffen wurde."

Gmail-Emails werden unbegrenzt gespeichert und bei Bedarf an Behörden herausgegeben. Googles automatische Email-Auswertung für Werbezwecke ist dabei nur die Spitze des Eisbergs. Google nutzt eure Daten auch in eigenen Rechtsstreitigkeiten: Im Waymo-vs-Uber-Fall präsentierte Google die Suchverläufe eigener Ex-Mitarbeiter vor Gericht – Suchanfragen wie "wie lösche ich Google Drive Dateien permanent von meinem Computer" wurden gegen sie verwendet.

Die bittere Wahrheit: Alle großen US-Tech-Konzerne kooperieren mit Behörden, wenn es darauf ankommt. Der Unterschied zu Microsoft ist graduell, nicht prinzipiell. Während Microsoft eure BitLocker-Schlüssel standardmäßig in der Cloud speichert, tut Apple dasselbe mit iCloud-Backups (außer ihr aktiviert manuell Advanced Data Protection). Während Microsoft auf richterliche Anordnung Schlüssel herausgibt, tut Apple dasselbe mit Backup-Daten.

Microsoft ist nicht die einzige Gefahr – es ist nur die offensichtlichste. Wer seine Daten wirklich schützen will, darf sich nicht auf das Marketing von Tech-Konzernen verlassen, egal ob Microsoft, Apple oder Google. Die einzige verlässliche Lösung ist echte, lokale Verschlüsselung ohne Cloud-Speicherung – wie sie LUKS unter Linux bietet.

Microsoft behauptet seit 2013, Hintertüren abgelehnt zu haben – die Realität sieht anders aus

Microsoft betont öffentlich, dass US-Sicherheitsbehörden bereits 2013 den Einbau einer Hintertür in BitLocker gefordert hätten und man sich dem verweigert habe. Diese Aussage klingt nach Widerstand gegen staatliche Überwachung – ist aber blanker Hohn angesichts der Tatsachen.

Wozu eine zusätzliche Hintertür einbauen, wenn die vorhandene Architektur bereits vollständigen Zugriff ermöglicht? Indem Microsoft eure BitLocker-Schlüssel standardmäßig in seiner Cloud speichert, hat der Konzern faktisch eine Hintertür geschaffen – nur dass diese nicht als solche bezeichnet werden muss. Die öffentliche Verweigerungshaltung ist PR, die Praxis ist Massenüberwachungsinfrastruktur.

LUKS unter Linux: So geht echte Verschlüsselung

Die gute Nachricht: Es gibt Alternativen. Unter Linux-Systemen kommt standardmäßig LUKS (Linux Unified Key Setup) zum Einsatz – ein Open-Source-Verschlüsselungssystem, das echte Sicherheit bietet.

Der fundamentale Unterschied: Bei LUKS bleiben alle Schlüssel ausschließlich auf eurem eigenen System. Es gibt keine Cloud-Speicherung, keine automatische Übertragung, keine zentrale Stelle, die Zugriff hat. Euer Schlüssel existiert nur auf eurer Hardware – und damit habt ihr die vollständige Kontrolle.

LUKS basiert auf dem dm-crypt-Kernel-Modul und setzt auf bewährte Verschlüsselungsalgorithmen wie AES. Der gesamte Code ist Open Source, kann von Sicherheitsforschern weltweit überprüft werden und wird von der Community kontinuierlich auf Schwachstellen untersucht. Das Gegenteil von Microsofts geschlossener, intransparenter BitLocker-Implementierung.

Die Einrichtung von LUKS erfolgt bei den meisten Linux-Distributionen (Ubuntu, Fedora, Debian, etc.) bereits während der Installation. Ihr wählt ein starkes Passwort – fertig. Kein Microsoft-Konto, keine Cloud, keine Hintertüren. Die Verschlüsselung ist standardmäßig so stark, dass selbst Geheimdienste mit massiver Rechenleistung eure Daten nicht entschlüsseln können – vorausgesetzt, ihr nutzt ein sicheres Passwort.

LUKS unterstützt außerdem Multiple-Key-Slots: Ihr könnt mehrere Passwörter oder Schlüsseldateien für denselben verschlüsselten Container einrichten, etwa für verschiedene Teammitglieder. Ihr könnt Schlüssel jederzeit hinzufügen oder entfernen, ohne die gesamte Partition neu verschlüsseln zu müssen. Echte Kontrolle, echte Flexibilität. Es können auch nachträglich Ordner mit LUKS verschlüsselt werden.

Wie überprüft ihr, ob euer BitLocker-Schlüssel in der Microsoft-Cloud liegt

Falls ihr Windows nutzt, solltet ihr sofort überprüfen, ob Microsoft euren BitLocker-Schlüssel gespeichert hat:

1. Meldet euch bei eurem Microsoft-Konto an (account.microsoft.com)
2. Navigiert zu „Geräte" und dann zu „BitLocker-Wiederherstellungsschlüssel"
3. Wenn dort Schlüssel aufgelistet sind, hat Microsoft Vollzugriff auf eure verschlüsselten Festplatten

Die Funktion lässt sich deaktivieren – allerdings müsst ihr eure BitLocker-Schlüssel dann selbst sicher verwahren. Verliert ihr sie, sind eure Daten unwiederbringlich verloren. Das ist der Preis echter Sicherheit: Eigenverantwortung statt bequemer Überwachung. Leider ist es jedoch fraglich, ob die Keys dann auch wirklich von den Servern gelöscht sind, die Antwort darauf, kann sich jeder selber geben..

Die bessere Lösung: Steigt auf Linux mit LUKS um. Open Source, transparent, sicher.

Trump 2.0: Die nächste Runde im Crypto-Krieg

Mit Donald Trumps Rückkehr ins Weiße Haus im Januar 2025 dürfte das Thema Verschlüsselung und Behördenzugriff wieder auf die politische Agenda rücken. Trump attackierte bereits in seiner ersten Amtszeit Tech-Konzerne wegen ihrer Verschlüsselungssysteme – insbesondere Apple.

Die entscheidende Frage: Wird Microsoft unter einer Trump-Administration noch stärker unter Druck geraten, den Behördenzugriff auszuweiten? Oder wird Microsoft – wie in der Vergangenheit – bereitwillig kooperieren, während sich andere Konzerne wehren?

Für euch als Nutzer bedeutet das: Die Bedrohung für eure Privatsphäre durch staatliche Überwachung wird nicht abnehmen. Im Gegenteil. Umso wichtiger ist es, jetzt auf echte Verschlüsselung zu setzen – auf Systeme, die technisch keine Hintertüren ermöglichen.

Soll ich Bitlocker deaktivieren

Nein, Bitlocker ist ein Schutz gegen Datendiebstahl durch physischen Zugriff auf eure Hardware. Solltet ihr den Laptop verlieren, oder wird dieser gestohlen, ist Bitlocker ein effektiver Schutz gegen Zugriff auf die Daten durch unbefugte Dritte. Jemand der die Festplatte ausbaut, hat somit keinen Zugriff auf die Daten auf der verschlüsselten Festplatte. Ohne Bitlocker kann jeder, der die Platte ausbaut, eure Daten kinderleicht auslesen.

Fazit: Microsofts BitLocker ist Sicherheitstheater, kein Schutz

BitLocker mit aktivierter Cloud-Speicherung ist keine Verschlüsselung im eigentlichen Sinne – es ist Sicherheitstheater. Es vermittelt euch ein falsches Gefühl von Sicherheit, während eure Daten für Microsoft und US-Behörden jederzeit zugänglich bleiben.

Die Geschichte von NSAKEY bis zur aktuellen FBI-Affäre zeigt: Microsoft hat eine lange Tradition der Kooperation mit Geheimdiensten. Der Konzern trifft bewusst Architekturentscheidungen, die Massenüberwachung ermöglichen, und schiebt die Verantwortung heuchlerisch auf euch als Nutzer ab.

Echte Sicherheit gibt es nur mit echter Verschlüsselung. LUKS unter Linux bietet genau das: Open Source, transparent, ohne Hintertüren. Eure Schlüssel bleiben auf eurem System, unter eurer Kontrolle. Kein Konzern, keine Behörde, niemand hat Zugriff – außer ihr selbst.

Weiterführende Links:

• LUKS-Dokumentation: https://gitlab.com/cryptsetup/cryptsetup
• EFF Guide: Surveillance Self-Defense
• Microsofts BitLocker-Schlüssel https://account.microsoft.com/devices überprüfen:

Hinweis: Ihr könnt bei uns in den Kommentaren gerne eure Erfahrungen mit BitLocker oder LUKS teilen. Habt ihr bereits auf Linux umgestellt? Welche Hürden gab es? Lasst es uns wissen!

The post BitLocker-Skandal: Microsoft liefert eure Festplattenschlüssel an das FBI appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Die meisten ASIC Miner laufen nicht optimal ab Werk. Hersteller setzen konservative Standardeinstellungen, um zu garantieren, dass alle Chips - selbst die schwächsten aus der Produktion - stabil laufen. Das bedeutet aber auch: Euer spezifischer Chip könnte deutlich mehr leisten, effizienter arbeiten oder mit weniger Spannung auskommen. Jeder Chip ist anders, und genau hier liegt euer Potenzial!

Was euch in diesem Guide erwartet:

Lernt die Geheimnisse des Core Voltage & Frequency Tuning kennen - die beiden wichtigsten Parameter, die über Performance, Effizienz und Stabilität eurer Mining-Hardware entscheiden. Ob ihr nun:

• Probleme beheben wollt: Niedrige Hashrates, instabile Chips oder Hardware-Errors beseitigen
• Effizienz steigern möchtet: Bis zu 20-30% weniger Stromverbrauch bei minimalem Hashrate-Verlust (Undervolting)
• Maximum Performance anstrebt: Sicher übertakten für 5-15% mehr Hashrate (Overclocking)

Dieser umfassende Guide deckt alle drei Szenarien ab - von der Diagnose über die Optimierung bis hin zum sicheren Pushen eurer Hardware-Grenzen. Mit konkreten Beispielen, Schritt-für-Schritt-Anleitungen und technischem Hintergrundwissen ausgestattet, werdet ihr nach diesem Artikel genau wissen, wie ihr das Maximum aus euren Mining-Geräten herausholt!

Anfänger-Hinweis: Falls ihr neu in der Mining Welt seid, empfehlen wir euch, zunächst die Bitcoin Mining Bibel zu lesen, damit ihr die Grundlagen des Minings kennen lernt.

Quick Explain: Spannung & Frequenz

Core Voltage

Stellt euch dies als die Stromversorgung des Mining-Chips' Gehirn (dem Core) vor. Gemessen in Millivolt (mV), bestimmt es, wie viel elektrische Energie dem Chip für seine Berechnungen zur Verfügung steht.

Zu niedrige Spannung führt zu Instabilität ungültigen Shares ("Invalid Shares" oder "Summit-Fehler") und somit zu schlechterer Leistung; zu hohe Spannung erhöht die Wärmeerzeugung dramatisch und riskiert Beschädigungen.

Technischer Hintergrund: Der Chip führt im Grunde Berechnungen durch, bei denen Transistoren zwischen An- und Ausgängen schalten. Eine niedrigere Spannung führt dazu, dass diese Übergänge nicht schnell genug erfolgen oder fehlschlagen, besonders bei höheren Frequenzen. Die Spannung bestimmt auch den Schwellenwert, den die Transistoren erreichen müssen – unter diesem Punkt funktioniert der Chip nicht mehr zuverlässig.

Taktfrequenz

Gemessen in Megahertz (MHz), ist dies die Geschwindigkeit, mit der der Chip seine Hash-Berechnungen durchführt.

Höhere Frequenz = mehr Berechnungen pro Sekunde = potentiell höhere Hashrate, aber es benötigt auch mehr Stromzufuhr und erzeugt wesentlich mehr Wärme.

Technischer Kontext: Die Frequenz bestimmt, wie viele Male pro Sekunde die internen Logik-Gatter schalten. Bei SHA-256 (Bitcoin Mining) müssen Millionen von logischen Operationen pro Hash durchgeführt werden. Die Frequenz multipliziert sich direkt in der Hashrate-Berechnung.

Die tiefe Verbindung: Voltage × Taktfrequenz

Diese zwei Einstellungen sind nicht unabhängig.

Frequenz erhöhen erfordert Spannung: Wenn ihr die Frequenz erhöht, schalten die Transistoren schneller. Dies erfordert jedoch, dass die Spannung hoch genug ist, um diese schnelleren Übergänge zuverlässig zu treiben. Eine zu niedrige Spannung bei hoher Frequenz führt zu "Timing Violations" – der Chip kann seine Operationen nicht in der geforderten Zeit abschließen.

Spannung erhöhen kostet Energie & Wärme: Eine höhere Spannung bedeutet, dass mehr Strom durch die Transistoren fließt. Dies folgt dem Ohmschen Gesetz: P = V² × I / R. Da die Verlustleistung mit dem Quadrat der Spannung zunimmt (oder mit V × I), steigt die Wärmeerzeugung superlinear – eine kleine Spannungserhöhung kann zu einer großen Temperaturerhöhung führen.

Effizienzkurve (J/TH): Energieeffizienz wird in Joules per Terahash (J/TH) gemessen. Der optimale Punkt für die meisten ASIC-Chips liegt typischerweise im mittleren Spannungsbereich (nicht zu niedrig, nicht zu hoch) und bei einer Frequenz, die nicht zu weit über dem Factory Default liegt. Das "sweetspot" variiert stark je nach Chip und Batch.

Gibt es eine universelle "beste" Einstellung

Die kurze Antwort: Nein.

Die Werkseinstellungen (z.B. 1150mV / 550MHz für einen ASIC Chip wie den BM1370) sind lediglich sichere Startpunkte, die auf Durchschnittswerten über tausende von Chips basieren.

Warum Variationen existieren:

1. Silizium-Loterie (Silicon Binning): Auch Chips aus demselben Produktionslos zeigen geringfügige physikalische Variationen. Der Halbleiterprozess ist nicht perfekt – Dotierungskonzentrationen, Transistorgeometrie und andere Parameter weichen leicht ab. Das bedeutet, dass jeder Chip ein leicht unterschiedliches Optimal-Fenster für Spannung/Frequenz hat.
2. Thermal Interface & Wärmeableitung: Die Qualität der Wärmepaste, die Aufpressdruck und die Anbindung des Heatsinks variieren zwischen Chips. Ein Chip mit besserer thermischer Anbindung kann höhere Frequenzen bei gleicher Temperatur tolerieren.
3. Power Delivery: Die Qualität der Stromversorgung und die Stabilität eurer PSU beeinflussen, welche Spannungen zuverlässig geliefert werden können.
4. Umgebungstemperatur & Kühlung: Ein Miner in einer kalten Umgebung mit ausgezeichnetem Airflow wird anders OC-grenzen haben als einer in einem warmen Serverraum.

Wann ist dieser Leitfaden relevant

Dieser Guide ist für 3 Szenarien sinnvoll:

1. Performance-Optimierung (Overclocking – OC)

Sicher zusätzliche Performance heraus holen – natürlich mit Vorsicht!

2. Undervolting und Effizienz Tuning

Möchtet ihr die maximale Effizienz aus eurem Miner herausholen, dann seid ihr in diesen Abschnitt genau richtig. Wir senken die ASIC Spannung so ab, damit der Stromverbrauch sinkt, und die Effizienz des Geräts steigt. Das gute daran, es ist praktisch nicht gefährlich.

3. Troubleshooting Underperforming Chips

Wenn euer Miner-Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "HW Errors") zeigt, oder die Gesamthashrate konsistent unter Erwartungen liegt – dies deutet oft auf unzureichende Core Voltage für die aktuelle Frequenz hin.

Häufige Fehler:

• Low Hashrate: Der Chip hasht, sendet aber weniger als erwartete Shares
• Invalid Shares: Der Chip produziert ungültige Hashes (falsche Berechnungen)
• Hardware Errors (HW): Der Chip schlägt bei der Verarbeitung fehl

Vorbereitungen

Macht euch mit dem User Interface von AxeOS oder der NerdQ Geräte vertraut. Beide Geräte bieten eine saubere und übersichtliche Oberfläche an, um die Performance der Geräte bestens zu überwachen.

AxeOS:

NerdQ OS:

In den Dashboards habt ihr den Überblick zur Hashrate, dem Stromverbrauch, die Input Voltage des Netztteils, die ASIC Spannung in Volt, die ASIC Temperatur, die VRM/VR Temperatur, die Lüfterdrehzahl und die Lüfterdrehzahl in Prozent. Diese Angaben helfen euch, den aktuellen Stand des Gerätes einzuschätzen.

OC Modus freischalten

In AxeOS müsst ihr Einstellungen/Settings des Gerätes, und dort den OC Modus freischalten. Dazu muss am Ende des Browserlinks ein

?oc=

angehängt werden. Aus

http://192.168.5.30/#/settings

wird

http://192.168.5.30/#/settings?oc=

Danach zeigt sich ein gelber Banner mit einem Warnhinweis:

Auf den NerdQ Geräten könnt ihr das über einen einfach Button tun:

Danach könnt ihr die Frequenzen und die Spannungen freier auswählen und feiner abstimmen

Lüftersteuerung kennen lernen

Bitaxen und NerdQ Geräte verfügen über eine automatische Lüftersteuerung, welche nach einem Temperatur Target arbeitet. Heisst also, die Lüfter Geschwindigkeit passt sich automatisch an die ASIC Temperatur an. Erhöht ihr Frequenz und Spannung, steigt nicht unbedingt die Chip Temperatur, sondern die Lüfterdrehzahl erhöht sich, bis das Maximum von 100% erreicht ist.

Aus Sicherheitsgründen sollte ein Lüfter nicht bei 100% im automatischen Modus laufen, da hier keinerlei Reserven mehr bestehen, vor allem, wenn es im Raum wärmer werden sollte. Ein gutes Temperatur Target liegt bei 60°c. Optimalerweise dreht der Lüfter dabei bei ca 50% seiner maximalen Drehzahl

Die Einstellungen dazu findet ihr in den Settings von NerdQ oder AxeOS:

Bei Geräten mit besseren Kühlern kann man das Temperatur Target auch etwas absenken, sollte sich der Kühler zu fest langweilen, und der Lüfter mit sehr niedriger Drehzahl arbeiten. Generel kann man sagen, dass sich kühlere Chips besser übertakten lassen.

Temperatur Grenzen der Bitaxen und NerdQ Geräten

Wichtig zu wissen: die ASIC Chips sollten wenn möglich 70° nicht überschreiten. Aus Sicherheitsgründen fahren die meissten Home Miner bei über 70° herunter. Danach schaltet sich der Überhitzungsschutz ein. Dieser wird euch deutlich in den Einstellungen der Miner angezeigt. Deaktiviert den Überhitzungsschutz, und stellt die Standardwerte der Chips wieder ein (BM1370 = 525mhz bei 1.15v)

Teil 1: Der vorsichtige Weg zum Overclocking

⚠️ WARNUNG: Overclocking birgt Risiken

Bevor ihr weiterlest, müsst ihr diese Risiken verstehen und akzeptieren:

1. Fortgeschrittenes Wissen erforderlich

• Ihr benötigt ein solides Verständnis von Elektronik, eurer spezifischen Hardware und Kühlungsgrenzen
• Ein naives "einfach mehr Frequenz" Experiment wird mit hoher Wahrscheinlichkeit zu Problem und Instabilitäten führen

2. Hardware-Schadensrisiko

• Bleibende Schäden möglich: Falsche Einstellungen können euren ASIC-Chips oder Hashboards permanent beschädigen
• Point of No Return: Einige Schäden (z.B. gebrannte Transistoren) können nicht repariert werden
• Kettenschaden-Effekt: Ein überhitzter Chip kann umliegende Komponenten beschädigen

3. Wärme & Effizienz Herausforderungen

• Overclocking kann die Wärmeerzeugung dramatisch erhöhen – potentiell um 50% oder mehr
• Power Consumption erhöht sich (gemessen in Watts): Dies ist nicht linear. Eine 10% Frequenzerhöhung + Spannungserhöhung könnte zu 20–30% mehr Stromverbrauch führen
• Effizienz sinkt (gemessen in J/TH – Joules pro Terahash): Wenn ihr 40% mehr Strom für 15% mehr Hashrate braucht, wurde eure Effizienz durch OC unverhältnismässig verschlechtert
• Lebensdauer der Hardware kann drastisch sinken (halbe Lebensdauer ist nicht selten bei aggressivem OC)

4. Kühlung ist existentiell

• Ihr solltet eine ausreichende Kühlung haben, bevor ihr OC versucht:
  • Niedrige Umgebungstemperaturen (idealerweise < 25°C)
  • optimierter Airflow, guter Lüfter
  • Hochwertige Heatsinks oder sogar Flüssigkeitskühlung für extreme OC
• Überhitzung ist der schnellste Weg zum Versagen. Ein überheizter Chip wird zum "Brick".

5. Garantieverlust

Overclocking führt zum Garantieverlust eures Gerätes. Wenn er durchbrennt, wars das. Es gibt sicherlich keinen Ersatz vom Verkäufer!

Wenn ihr die Risiken akzeptiert: Die methodische OC-Prozedur

Voraussetzungen

Bevor ihr ein einziges MHz erhöht, überprüft diese Bedingungen:

1. Baseline Stabilität

• Euer Miner läuft 100% stabil mit den aktuellen Einstellungen
• Keine unerklärten Fehler oder spontanen Reboots über Stunden hinweg
• Alle Chips senden konsistent gültige Shares und die erwartete Hashrate wird auch tatsächlich erreicht

2. Temperatur im grünen Bereich

• ASIC Core Temp liegt stabil bei ~60°C oder eurem eingestelltem Target
• VRM (Voltage Regulator) liegt unter ~70°C
• Der Lüfter dreht bei 50% seiner maximalen Drehzahl im automatischen Modus
• Diese "Sicherheitsmargen" geben euch Platz für die Wärmesteigerung durch OC

3. Stromversorgung mit Headroom

• Euer Netzteil hat 30% Kopfraum über dem aktuellen Stromverbrauch
  • Beispiel: Wenn euer Miner aktuell 75W zieht, sollte euer Netzteil mind. 110W haben
  • Grund: Netzteile die am Limit arbeiten PSUs werden instabil, liefern niedrigere Spannung, können ausfallen
• Überprüft die PSU-Kabelqualität (keine beschädigten, frayed oder überheizten Kabel)

Eine Bitaxe mit aussreichender Kühlung und genügend Spielraum:

Die Temperatur liegt bei 60°, der Lüfter ist erst bei 42%

Overclocking Schritt für Schritt durchführen

Schritt 1: Kleine Frequenzerhöhung

Erhöht die Frequenz für der Chips um +10 MHz (z.B. von 550 auf 560MHz).

Warum +10 MHz?

• Groß genug, um messbar zu sein (nicht in dem Rauschen der Mess-Variabilität)
• Klein genug, um bei Instabilität schnell zu erkennen
• Standard in der Mining-Community

Schritt 2: Speichern & Neustart

In neueren Version von AxeOS und NerdQ OS muss das Gerät nicht neugestartet werden.

Schritt 3: Kritisches Monitoring (15–30+ Minuten)

Das ist der wichtigste Schritt. Geht ins Dashboard und beobachtet intensiv:

3a) Stabilität & Submissions

• Sind alle Shares gültig? Keine neuen "Invalid Shares" oder "HW Errors"?
• Ist die beobachtete Hashrate nahe der erwarteten Hashrate für die neue Frequenz?
  • Die Firmware des Miners oder der Pool sollte euch die erwartete Rate für 560MHz anzeigen
  • Wenn eure beobachtete Hashrate sinkt oder unter der Erwartung liegt, ist das ein Zeichen, dass zu wenig Spannung am Chip anliegt
• Konsistenz: Ist die Hashrate stabil oder "flattert" sie?

3b) Temperatur-Überwachung

• Temperatur-Steigerung: Wieviel ist die Drehzahl des Lüfters, oder die Temperatur des ASICS und der VRMs durch die +10MHz Frequenzerhöhung gestiegen?

3c) Hardware Errors & Log-Überwachung

• Tauchen neue Fehler auf? Spezifisch:
  • nonce_range_err – kann auf Timing Violations hindeuten
  • device_hw_errors – Chip-Fehler
  • shares_stale – seltener, aber kann auf "zu lange Berechnung" hinweisen

Wo beobachten:

• Miner Web-Interface (Live Hashrate, Temperature, Error Counter)
• Pool Dashboard: Ist die Accepted vs. Rejected Rate stabil?

Das Dashboard zeigt eine stabile Temperatur, der Lüfter ist nicht ausgereizt, die VRMs bleiben schön kühl.

Schritt 4: Stabil? Wiederholt die Frequenzerhöhung

Falls alles ok ist nach 30 Minuten Monitoring:

1. Erhöht die Frequenz um weitere +10 MHz (z.B. 560 → 570MHz)
2. Speichert oder Startet neu bei älteren Versionen
3. Geht zurück zu Schritt 3 – monitort erneut

Typisches OC-Szenario:

550MHz (Baseline, stabil) 
→ 560MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 570MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 580MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 590MHz (+10) - stabil, +1°C, 0 Fehler, Temperatur OK ✓
→ 600MHz (+10) - stabil, +2°C, 0 Fehler, Temperatur OK ✓
→ a) 610MHz (+10) - instabil (Fehler oder Hashrate sinkt), Temperatur OK, x
→ b) 610MHz (+10) - stabil, Temperatur zu hoch, x

a) ihr müsst die ASIC Spannung um 10mv erhöhen und nochmals testen
b) ihr müsst für eine bessere Kühlung sorgen

Schritt 5: Instabilität erkennen und beheben

Wenn ihr nach 30 Minuten bei der neuen Frequenz Fehler oder niedriger Hashrate seht:

Diagnose:

• Die aktuelle Frequenz ist an der Grenze der Stabilität der Spannung
• ihr benötigt mehr Spannung, um diese Frequenz stabil zu halten
• ihr benötigt eine bessere Kühlung

Maßnahme: Core Voltage erhöhen

1. Erhöhe die Core Voltage um +10mV (z.B. 1150 → 1160mV) für die instabilen Chips
2. Speichern & Neustart
3. Monitort erneut (mindestens 30 Minuten)
4. Sehr wichtig: Monitor die Temperatur intensiv!
   • Eine Spannungserhöhung erzeugt disproportional mehr Wärme
   • Beispiel: +10mV könnte +3–4°C an Temperatur hinzufügen

Szenario-Beispiel:

Versuch: 610MHz @ 1150mV
→ Nach 10min: 50 Invalid Shares, Hashrate sinkt

Lösung: 610MHz @ 1160mV (Spannung +10mv)
→ Nach 30min: 0 Fehler, aber Temp ist von 60°C auf 65°C gestiegen ✓
→ Akzeptabel! Speichern.

Nächster Versuch: 620MHz @ 1160mV
→ Nach 15min: Neue Fehler, 645 Invalid Shares
→ Wieder Spannung erhöhen? Vielleicht nicht. Temp ist bereits bei 65°C.
→ Lieber bei 610MHz @ 1160mV stoppen.

In meinem Falle ist aufgrund der besseren Kühlung das Gerät immer noch bei 60°, aber der Lüfter dreht schon deutlich schneller bei 54%

Schritt 6: Überhitzung erkannt? (Stop!)

Wenn während eines Versuches die Temperaturen in den gefährlichen Bereich schießen:

Sichere Schwellenwerte (harte Limiten):

• ASIC Core Temp > 70°C: Gefährliche Zone. Der Chip kann sich automatisch abschalten.
• VRM Temp > 85°C: Kritisch. Mehr Airflow ist notwendig

Wenn ihr dies seht: sofort stoppen!

Maßnahme: Rollback

1. Revertiert die letzte Frequenz- oder Spannungserhöhung, die diese Temperaturen ausgelöst hat
   • Wenn die Temp bei 620MHz zu hoch wurde, gehe zurück auf 610MHz
   • Oder wenn die Temp bei 1170mV stieg, geht zurück auf 1160mV
2. Speichert & Startet erneut, verifiziert, dass Temps zurück zu sicheren Werten gehen
3. Danach: Um weiter zu gehen, benötigt ihr Kühlungs-Upgrades:
   • Bessere/stärkere Ventilatoren
   • Niedrigere Umgebungstemperatur
   • Flüssigkeitskühlung (für extreme OC)
   • Bessere Airflow-Umgebung

Warnung: Das Ignorieren von Temperaturwarnungen ist der sicherste Weg zu permanenten Hardware-Schäden oder Bränden. Respektiert die Grenzen.

Schritt 7: Die OC-Grenze finden

Wiederholt diese Zyklen (Freq erhöhen → Monitoren → Falls instabil, Spannung erhöhen → Monitoren temps):

Ihr stoppt, wenn eine der folgenden Bedingungen erfüllt ist:

1. Ihr hast dein Ziel-Performance-Level erreicht
   • Z.B. wolltet ihr 20% mehr Hashrate, und ihr habt sie erreicht bei akzeptablen Temps & Spannungen ✓
2. Instabilität lässt sich nicht mit mehr Spannung beheben
   • Z.B. bei 700MHz @ 1200mV ist immer noch instabil bei 700MHz @ 1250mV
   • Das bedeutet: Die Hardware kann diese Frequenz physikalisch nicht stabil halten (selbst mit höherer Spannung)
   • Das ist die Hardware-Grenze
3. Thermische Grenzen erreicht
   • ASIC Temps sind konsistent > 70°C
   • VRM Temps nähern sich 85°C
   • Weitere Erhöhungen würden zu Shutdowns oder Schäden führen

Die "ideale" OC-Zone:

• Frequenz-Gewinn: +10–15% über Baseline (z.B. 550 → 610MHz) ist "konservativ"
• Spannungs-Erhöhung: +20–30mV über Baseline ist "moderat"
• Temperatur-Erhöhung: +15°C über Baseline wird noch akzeptiert
• Alles darüber: Aggressives OC mit hohem Risiko

Die perfekte OC-Einstellung finden: Ein vollständiges Beispiel

Angenommen, eure Baseline ist:

Frequency: 550MHz
Core Voltage: 1150mV
Temp: 60°C
Hashrate: 1070 GH/s (100%)
Power Draw: 18
Efficiency: 16.0 J/TH
Standard Kühlblock und Lüfter

OC-Versuch Gerät Nummer 1 mit Standard Kühler, schlechter ASIC Chip:

Fazit: Optimales OC-Fenster liegt bei 590 MHz @ 1160 mV

Warum Schritt 3 statt Schritt 5?

Während Schritt 5 (630 MHz @ 1170 mV) die höchste Hashrate von 1300 GH/s erreicht, ist dies nicht das beste Gesamtpaket:

• Stabilität: Schritt 3 ist vollständig stabil (0 Fehler), Schritt 5 ist nur Borderline
• Temperatur: 63°C vs. 68°C – noch im grünen Bereich
• Effizienz: 17.0 J/TH ist deutlich besser als 19.0 J/TH bei Schritt 5
• Hashrate-Gewinn: +6,4% gegenüber Schritt 1 (1100 → 1170 GH/s)
• Stromeffizienz: +2W mehr Verbrauch, aber stabiles System

Schritt 5 als risikobereite Alternative:

• +18,2% Hashrate (1300 GH/s)
• Aber: Borderline-Status, höhere Temps, schlechtere Effizienz
• Nur für aggressive Mining-Szenarien ohne Langzeitstabilität gefordert

OC Versuch Gerät Nummer 2 mit The Bitchin' Sink Kühler und dem Gelid Black Magic und zusätzlichen Effizienz Tuning