Was Nextcloud kann und warum es eine Alternative zu Google Drive und Microsoft 365 ist, steht auf unserer Seite Was ist Nextcloud. Wer eine Synology besitzt, findet die klassische Installation über die Web Station in der Anleitung Nextcloud auf Synology DSM 7.2 installieren. Hier geht es um den anderen Weg: ein Linux-Server, ein Mini-PC im Keller oder ein gemieteter VPS, auf dem Docker läuft und Nextcloud sich weitgehend selbst verwaltet. Weitgehend, nicht vollständig — dazu gleich mehr.

Nextcloud AIO installieren: was der Mastercontainer eigentlich tut

Nextcloud All-in-One, kurz AIO, bezeichnet das Projekt selbst als „the official Nextcloud installation method“. Ihr startet genau einen Container, den sogenannten Mastercontainer. Der spricht über den Docker-Socket direkt mit dem Docker-Dienst auf eurem Server und legt alle weiteren Container selbst an. Das Projekt beschreibt das Prinzip in seiner Dokumentation auf GitHub als Anlehnung an Portainer: Ein Container steuert die übrigen, ihr bedient ihn über eine Weboberfläche.

Was dabei fest mitkommt, listet die Dokumentation auf:

• Apache-Container für HTTPS, mit automatisch bezogenem Let's-Encrypt-Zertifikat, HTTP/2 und HTTP/3
• Nextcloud-Container mit PHP-FPM, OPcache und APCu als lokalem Cache
• PostgreSQL als Datenbank
• Redis als verteilter Cache und für das Sperren von Dateien
• Notify Push, damit Desktop- und Mobil-Clients Änderungen ohne ständiges Nachfragen mitbekommen

Optional zuschaltbar sind unter anderem Nextcloud Office, Nextcloud Talk samt TURN-Server, ein Backup-Container auf Basis von BorgBackup, Imaginary für Vorschaubilder, ClamAV als Virenscanner, eine Volltextsuche und Whiteboard. Bis 100 Benutzer ist AIO laut Projekt kostenlos, darüber verweist Nextcloud auf sein Enterprise-Angebot.

Viele Handgriffe, die wir für manuelle Installationen beschrieben haben, entfallen damit. Den Cronjob für Nextcloud, das Einrichten von APCu und Redis oder das Beantragen des Zertifikats mit Certbot erledigt AIO selbst.

Der Preis der Bequemlichkeit: Zugriff auf den Docker-Socket

Damit der Mastercontainer andere Container starten kann, bekommt er den Docker-Socket /var/run/docker.sock eingebunden. Die Docker-Dokumentation sagt zur Angriffsfläche des Docker-Daemons unmissverständlich: „only trusted users should be allowed to control your Docker daemon.“ Wer den Daemon steuert, kann einen Container mit dem Wurzelverzeichnis des Hosts starten und das Dateisystem ohne Einschränkung verändern. Dass AIO den Socket mit :ro nur lesend einbindet, ändert daran nichts. Könnte der Mastercontainer über diesen Socket keine Befehle an Docker schicken, könnte er auch keine Container starten.

Ihr vertraut dem Nextcloud-Projekt also faktisch mit Root-Rechten auf diesem Server. Für einen Server, der nur Nextcloud betreibt, ist das ein vertretbarer Handel. Auf einer Maschine, auf der noch zehn andere Dienste laufen, solltet ihr ihn bewusst eingehen. Wer das nicht will, findet im Repository eine Variante ohne Socket-Zugriff, verliert damit aber genau die Automatik, um die es hier geht.

Bevor ihr anfangt: Server, Domain und Ports

AIO läuft auf x86-64 und auf ARM64. Welche Architektur euer Server hat, verrät uname -m: x86_64 oder aarch64 sind beide in Ordnung. Für den Speicher rät das Projekt zu einer SSD, eine Festplatte funktioniert, ist aber spürbar langsamer. SD-Karten, etwa in einem Raspberry Pi, raten die Entwickler ausdrücklich ab, weil Datenbank und Cache sie mit Schreibzugriffen zermürben.

Bei gemieteten Servern empfiehlt das Projekt VPS auf KVM-Basis und nennt ältere Strato-VPS auf Virtuozzo sowie VPS von Hostinger als bekannte Problemfälle.

Als Betriebssystem nehmen wir Debian 13 „Trixie“ oder Debian 12. Docker unterstützt laut Installationsanleitung für Debian genau diese beiden Versionen, für Ubuntu laut Anleitung für Ubuntu die LTS-Versionen 22.04, 24.04 und 26.04. Linux Mint führt Docker ausdrücklich nicht als unterstützt; für einen Server, der dauerhaft läuft, ist Debian ohnehin die ruhigere Wahl.

Ohne Domain geht es nicht

AIO verlangt eine Domain, die auf euren Server zeigt, und ein gültiges Zertifikat. Ein Betrieb nur über eine IP-Adresse ist laut Projekt nicht vorgesehen und wird auch nicht nachgerüstet. Habt ihr keine eigene Domain, hilft ein DynDNS-Name oder die in AIO eingebaute Registrierung einer kostenlosen Subdomain bei deSEC, dazu weiter unten mehr.

Welche Ports wohin gehören

Laut Dokumentation:

• 8080/TCP: die AIO-Oberfläche mit selbstsigniertem Zertifikat. Nur für euch, nur im LAN oder über einen SSH-Tunnel.
• 443/TCP: Nextcloud selbst über den Apache-Container. Muss vom Internet erreichbar sein. 443/UDP zusätzlich, wenn ihr HTTP/3 wollt.
• 3478/TCP und 3478/UDP: der TURN-Server von Nextcloud Talk, nur nötig, wenn ihr Talk aktiviert.
• 80/TCP und 8443/TCP: optional, für ein gültiges Zertifikat der AIO-Oberfläche. Hinter einem Reverse Proxy entfallen beide.

Als zwingend offen nennt das Projekt nur 443 und, falls Talk läuft, 3478. Die folgende Grafik zeigt, wie das zusammenhängt.

Entscheidet euch jetzt für eine von zwei Varianten. Variante A: Auf dem Server läuft sonst kein Webserver, AIO bekommt Port 443 selbst. Variante B: Es gibt schon einen Reverse Proxy wie Caddy oder nginx, AIO läuft dahinter. Die Schritte 1 und 2 sind für beide gleich, ab Schritt 3 trennen sich die Wege.

Schritt 1: Docker aus dem offiziellen Repository installieren

Unsere Grundlagenanleitung Docker Basics und Installation auf Mint, Ubuntu und Debian erklärt Images, Container und Volumes. Für AIO folgen wir hier der aktuellen offiziellen Anleitung von Docker, weil sie das Compose-Plugin gleich mitinstalliert und das neue Format für Paketquellen verwendet.

Zuerst entfernt ihr Pakete, die mit der offiziellen Docker-Version kollidieren. Sind keine installiert, meldet apt das einfach:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Dann den Schlüssel und die Paketquelle von Docker einrichten. Der Befehl ist für Debian geschrieben:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

Unter Ubuntu ersetzt ihr in den beiden Adressen debian durch ubuntu. Danach installiert ihr Docker samt Compose-Plugin und prüft, ob alles läuft:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Erscheint die Begrüssung von Docker, ist die Grundlage gelegt. Unter Ubuntu prüft ihr zusätzlich, ob nicht noch eine Snap-Version von Docker im System steckt. AIO unterstützt sie ausdrücklich nicht:

sudo docker info | grep "Docker Root Dir" | grep "/var/snap/docker/"

Kommt hier /var/snap/docker/ zurück, läuft das falsche Docker. Laufen darin noch Container, sichert ihr diese zuerst, bevor ihr den Snap mit sudo snap remove docker entfernt.

Schritt 2: Docker umgeht eure Firewall

Hier kann eine Tür offen bleiben, ohne dass ihr es merkt. Die Docker-Dokumentation zu Paketfiltern und Firewalls hält fest, dass veröffentlichte Container-Ports an ufw vorbeigehen: Der Verkehr wird umgeleitet, bevor er die Regeln von ufw überhaupt erreicht. Die Installationsanleitung warnt dasselbe für firewalld.

Heisst konkret: Ihr könnt mit ufw deny 8080 so viel sperren, wie ihr wollt. Veröffentlicht Docker den Port, ist er offen. Auf einem Server im Heimnetz hinter einem Router ist das halb so wild, solange ihr am Router nur 443 (und gegebenenfalls 3478) weiterleitet. Auf einem gemieteten VPS mit öffentlicher IP liegt die AIO-Oberfläche dagegen ungeschützt im Internet.

Die saubere Lösung ist, Port 8080 nur auf 127.0.0.1 zu veröffentlichen. Laut der Docker-Dokumentation zur Portveröffentlichung ist der Port dann nur noch vom Docker-Host selbst erreichbar. Eine Einschränkung nennt die Seite: Bei Docker-Versionen vor 28.0.0 konnten Rechner im selben Netzsegment trotzdem zugreifen. Mit der Version aus dem offiziellen Repository seid ihr auf dem aktuellen Stand.

An die Oberfläche kommt ihr dann über einen SSH-Tunnel von eurem Rechner aus:

ssh -L 8080:127.0.0.1:8080 benutzer@euer-server

Solange diese Verbindung offen ist, erreicht ihr die AIO-Oberfläche in eurem Browser unter https://127.0.0.1:8080.

Schritt 3: Den Mastercontainer starten (Variante A)

Für den Dauerbetrieb empfiehlt das Projekt eine Compose-Datei statt eines langen docker run-Befehls. Legt ein Verzeichnis an und darin die Datei compose.yaml. Die Vorlage stammt aus der offiziellen compose.yaml, gekürzt auf das Nötige:

sudo mkdir -p /opt/nextcloud-aio
sudo nano /opt/nextcloud-aio/compose.yaml

name: nextcloud-aio
services:
  nextcloud-aio-mastercontainer:
    image: ghcr.io/nextcloud-releases/all-in-one:latest
    init: true
    restart: always
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    network_mode: bridge
    ports:
      - "80:80"
      - "127.0.0.1:8080:8080"
    # environment:
    #   NEXTCLOUD_DATADIR: /mnt/ncdata
    #   NEXTCLOUD_UPLOAD_LIMIT: 16G
volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

Drei Namen in dieser Datei dürft ihr nicht ändern: den Containernamen nextcloud-aio-mastercontainer, weil die Updates des Mastercontainers davon abhängen, sowie den Volume-Namen nextcloud_aio_mastercontainer an beiden Stellen, weil das eingebaute Backup darauf angewiesen ist. Gegenüber der Vorlage haben wir zwei Dinge geändert: Port 8080 ist an 127.0.0.1 gebunden, wie in Schritt 2 begründet, und Port 8443 fehlt. Über ihn liefert AIO die Oberfläche mit gültigem Zertifikat aus, was ihr mit dem SSH-Tunnel nicht braucht; auf einem VPS stünde sie sonst wegen der Firewall-Falle offen im Internet. Port 80 leitet Besucher auf Nextcloud weiter und darf bleiben. Wollt ihr die Oberfläche lieber aus dem LAN direkt aufrufen, schreibt ihr dort "8080:8080" und sorgt am Router dafür, dass 8080 nicht weitergeleitet wird.

Was ihr vor dem ersten Start festlegen müsst

Einige Einstellungen wirken nur beim ersten Start oder lassen sich später nur mit Aufwand ändern. Wollt ihr sie setzen, entfernt ihr die Raute vor environment: und vor der jeweiligen Zeile:

• NEXTCLOUD_DATADIR legt fest, wo auf dem Host eure Dateien liegen, etwa auf einer eigenen Platte unter /mnt/ncdata. Der Pfad muss mit / beginnen und darf nicht / selbst sein. Diesen Wert nach der Erstinstallation nicht mehr ändern, das Projekt warnt ausdrücklich davor. Liegt dort ein Btrfs-Laufwerk, nehmt einen Unterordner wie /mnt/ncdata/nextcloud.
• NEXTCLOUD_UPLOAD_LIMIT begrenzt Uploads, die nicht in Teilen übertragen werden, also vor allem über öffentliche Links. Angemeldete Benutzer laden über Web, Desktop- und Mobil-Client ohnehin in Teilen hoch. Der Wert muss mit einer Zahl beginnen und mit G enden.
• NEXTCLOUD_MEMORY_LIMIT setzt das Speicherlimit je PHP-Prozess, Vorgabe sind 512 MB.
• NEXTCLOUD_STARTUP_APPS bestimmt, welche Apps beim ersten Start installiert werden, zum Beispiel deck twofactor_totp tasks calendar contacts notes.

Zum Upload-Limit widerspricht sich die Dokumentation selbst: Die Funktionsliste nennt 10 GB über öffentliche Links, das FAQ 1G. Wer grosse Dateien per Link empfangen will, setzt den Wert deshalb ausdrücklich.

Dann startet ihr den Mastercontainer:

cd /opt/nextcloud-aio
sudo docker compose up -d
sudo docker logs -f nextcloud-aio-mastercontainer

Die Logs verlasst ihr mit Strg+C, der Container läuft weiter.

Schritt 4: AIO-Oberfläche, Passphrase und Domain

Öffnet nun die AIO-Oberfläche: über den SSH-Tunnel unter https://127.0.0.1:8080, im LAN unter https://<IP-des-Servers>:8080. Der Browser warnt vor dem selbstsignierten Zertifikat, das ist hier beabsichtigt und wird akzeptiert.

Ruft diese Oberfläche immer über die IP-Adresse auf, nie über eure Domain. Die Dokumentation warnt, dass das zwar anfangs funktionieren kann, später aber durch HSTS blockiert wird: Hat euer Browser einmal gelernt, dass die Domain nur mit gültigem Zertifikat aufgerufen werden darf, lässt er euch an das selbstsignierte Zertifikat auf Port 8080 nicht mehr heran.

Die Oberfläche zeigt euch beim ersten Aufruf eine Passphrase. Speichert sie in eurem Passwortmanager, ihr braucht sie für jede spätere Anmeldung. Danach gebt ihr die Domain ein, unter der Nextcloud erreichbar sein soll, zum Beispiel cloud.example.ch. AIO prüft, ob die Domain auf diesen Server zeigt und Port 443 erreichbar ist. Schlägt die Prüfung fehl, stimmt meistens die Portweiterleitung oder der DNS-Eintrag nicht, siehe Fehlerbehebung weiter unten.

Anschliessend wählt ihr die optionalen Container aus. Für den Anfang reicht wenig: Nextcloud Office, wenn ihr Dokumente im Browser bearbeiten wollt, Talk nur, wenn ihr Port 3478 tatsächlich freigeben wollt. Jeder zusätzliche Container kostet Arbeitsspeicher und will aktualisiert werden. Mit „Start containers“ lädt AIO die Abbilder herunter und startet alles. Das dauert beim ersten Mal einige Minuten. Danach zeigt euch die Oberfläche die Anmeldedaten des ersten Administratorkontos. Notiert sie sofort.

Eine Eigenheit, über die viele stolpern: Solange Nextcloud läuft, ist die direkte Anmeldung an der AIO-Oberfläche mit der Passphrase gesperrt. Ihr meldet euch dann als Administrator in Nextcloud an und öffnet https://cloud.example.ch/settings/admin/overview. Dort erscheint oben eine Schaltfläche, die euch für diese Browsersitzung zur AIO-Oberfläche durchlässt. Sind die Container gestoppt, gilt die Sperre nicht.

Damit läuft eure Nextcloud. Das war der angenehme Teil. Der Rest handelt davon, was eine Installation von einem Betrieb unterscheidet.

Variante B: Nextcloud AIO hinter Caddy betreiben

Läuft auf eurem Server schon ein Reverse Proxy, darf AIO Port 443 nicht für sich beanspruchen. Wie ihr Caddy einrichtet, steht in Caddy Reverse Proxy einrichten. Für AIO gelten laut Reverse-Proxy-Dokumentation des Projekts drei Änderungen gegenüber Variante A.

Erstens bekommt der Apache-Container einen anderen Port und lauscht nur lokal. In der compose.yaml fällt Port 80 weg, dafür kommen zwei Umgebungsvariablen dazu:

    ports:
      - "127.0.0.1:8080:8080"
    environment:
      APACHE_PORT: 11000
      APACHE_IP_BINDING: 127.0.0.1

APACHE_IP_BINDING: 127.0.0.1 ist nur richtig, wenn Caddy auf demselben Host läuft und AIO über localhost anspricht. Läuft der Proxy auf einer anderen Maschine, setzt ihr hier 0.0.0.0 und schützt den Port anders.

Zweitens leitet Caddy die Domain an diesen Port weiter. Das Projekt nennt Caddy ausdrücklich als empfohlenen Proxy, der Block im Caddyfile ist entsprechend kurz:

cloud.example.ch {
    reverse_proxy localhost:11000
}

Die config.php-Einträge aus dem Nextcloud-Abschnitt unserer Caddy-Anleitung braucht AIO nicht. Nur wenn euer Proxy AIO nicht über localhost oder 127.0.0.1 erreicht, tragt ihr seine Adresse als vertrauenswürdigen Proxy ein:

sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ config:system:set trusted_proxies 2 --value=192.168.1.10

Drittens startet ihr AIO mit sudo docker compose up -d neu, öffnet die Oberfläche wie in Schritt 4 und gebt dieselbe Domain ein, die im Caddyfile steht. Die Domainprüfung läuft jetzt durch Caddy hindurch.

Zu Hause ohne eigene Domain: deSEC und der Zugriff aus dem LAN

Für Server im Heimnetz hat AIO eine Abkürzung eingebaut. Auf der Seite zur Domaineingabe findet sich der Abschnitt „Don't have a domain? Get a free one from deSEC“. Gebt eine E-Mail-Adresse und auf Wunsch einen Namen für die Subdomain ein, und AIO registriert eine Subdomain unter dedyn.io bei deSEC, einem DNS-Dienst, der laut eigener Angabe für alle kostenlos ist. Laut Dokumentation hält der Mastercontainer den DNS-Eintrag danach selbst aktuell, wenn sich eure öffentliche IP ändert, und schaltet zwei Community-Container zu: Caddy als Reverse Proxy und dnsmasq für die Namensauflösung im LAN.

Ruft ihr cloud.example.ch von zu Hause aus auf, muss euer Router die Anfrage an den eigenen Server zurückschicken. Viele Router beherrschen dieses sogenannte Hairpin NAT nicht. Die Dokumentation nennt zwei Auswege: Hairpin NAT im Router aktivieren, falls er es kann, oder einen lokalen DNS-Server betreiben, der die Domain im LAN auf die interne IP des Servers auflöst. Bei der deSEC-Variante übernimmt das der dnsmasq-Container, sobald ihr im Router den DHCP-DNS-Server auf euren AIO-Host umstellt. Die Einzelheiten stehen in der Dokumentation zum lokalen Betrieb.

Und dann gibt es noch die Anschlüsse, bei denen gar nichts von aussen ankommt. Laut Fehlerbehebung des Projekts lassen sich hinter CGNAT keine Ports öffnen. Habt ihr nur eine öffentliche IPv6-Adresse, etwa bei DS-Lite, muss IPv6 in Docker und auf dem ganzen Weg aktiviert sein, samt AAAA-Eintrag für die Domain.

Backup mit BorgBackup: einrichten, bevor ihr Daten hochladet

AIO bringt eine eigene Sicherung auf Basis von BorgBackup mit. Laut Dokumentation sind die Sicherungen inkrementell, komprimiert und verschlüsselt, nur die erste dauert länger. Gesichert werden Datenbank, Dateien und die Konfiguration des Mastercontainers, also alles, was für eine Wiederherstellung nötig ist. Was nicht gesichert wird: Ordner, die ihr über die App „External storage“ in Nextcloud eingebunden habt.

Die Einrichtung geht so:

1. Bindet eine externe oder zweite Platte im Host ein, am besten unter /mnt/backup.
2. Tragt diesen Pfad in der AIO-Oberfläche im Backup-Abschnitt als Sicherungsverzeichnis ein.
3. Klickt auf „Create Backup“. Die erste Sicherung dauert je nach Datenmenge eine Weile, alle weiteren übertragen nur Änderungen.
4. Speichert den angezeigten Schlüssel sofort an einem sicheren Ort ausserhalb dieses Servers. Ohne ihn lässt sich keine Sicherung wiederherstellen.
5. Aktiviert danach die tägliche Sicherung. Dabei lässt sich zusätzlich einschalten, dass AIO im Anschluss alle Container, Nextcloud und die Apps automatisch aktualisiert.

Statt eines lokalen Pfads akzeptiert AIO auch ein entferntes Borg-Repository. Der erste Versuch schlägt dann absichtlich fehl: AIO erzeugt ein SSH-Schlüsselpaar und zeigt den öffentlichen Schlüssel an, den ihr beim Ziel in die authorized_keys eintragt.

Die Vorgabe zur Aufbewahrung lautet --keep-within=7d --keep-weekly=4 --keep-monthly=6: alles der letzten sieben Tage, dazu vier Wochen- und sechs Monatsstände. Mit der Umgebungsvariable BORG_RETENTION_POLICY lässt sie sich ändern. Eine Sicherung auf einer Platte, die im selben Gehäuse steckt, schützt vor einem kaputten Update, aber nicht vor Feuer, Diebstahl oder Verschlüsselungstrojanern. Warum es eine zweite Kopie an einem anderen Ort braucht, erklärt Was ist ein gutes Backup: die 3-2-1-Regel erklärt. Ein Borg-Repository bei einem externen Anbieter oder auf einem zweiten Server ist dafür der naheliegende Weg.

Updates und occ-Befehle im Alltag

Neue Versionen der Container meldet die AIO-Oberfläche unter dem Abschnitt „Containers“. Ihr klickt auf „Stop containers“ und danach auf „Start and update containers“. Erstellt vorher eine Sicherung, dann geht es bei einem misslungenen Update mit einem Klick zurück. Der Mastercontainer hat ein eigenes Update: Ist eine neue Fassung da, erscheint bei gestoppten Containern eine eigene Schaltfläche dafür.

Laut Dokumentation schickt AIO samstags eine Benachrichtigung an die Administratoren, wenn Updates bereitliegen. Ist das Nextcloud-Abbild älter als 90 Tage, kommt jeden Tag eine Warnung mit dem Titel „AIO is outdated!“. Einmal im Quartal ist also das Minimum; wer die tägliche Sicherung mit automatischen Updates kombiniert, muss sich kaum noch darum kümmern.

Für alles, was die Oberfläche nicht kann, gibt es das Kommandozeilenwerkzeug occ. Bei AIO ruft ihr es im Nextcloud-Container als Benutzer www-data auf, zum Beispiel für einen Systemcheck oder eine Liste der Benutzer:

sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ status
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ user:list

Die Logdatei von Nextcloud liegt bei einer Standardinstallation unter /var/lib/docker/volumes/nextcloud_aio_nextcloud/_data/data/nextcloud.log. Diesen Pfad nennt die Dokumentation für Fail2ban und weist darauf hin, dass in der Jail-Konfiguration chain=DOCKER-USER stehen muss, sonst bleibt Nextcloud trotz Sperre erreichbar. Dieselbe Firewall-Falle wie in Schritt 2, nur von der anderen Seite.

Wenn etwas nicht klappt

Die meisten Probleme entstehen beim ersten Einrichten und haben wiederkehrende Ursachen. Hier die häufigsten, gestützt auf die Fehlerbehebung des Projekts.

Die Domainprüfung schlägt fehl

Prüft zuerst, ob der DNS-Eintrag der Domain auf eure öffentliche IP zeigt und ob Port 443 am Router auf den Server weitergeleitet ist. Hinter CGNAT kann die Prüfung nicht gelingen. Bei Cloudflare als Proxy kann Cloudflare die Prüfung blockieren. Als letztes Mittel nennt das Projekt die Variable SKIP_DOMAIN_VALIDATION: true, ausdrücklich nur, wenn ihr sicher seid, dass alles richtig eingerichtet ist.

Die AIO-Oberfläche ist nicht mehr erreichbar

Habt ihr Port 8080 einmal über die Domain aufgerufen, sperrt euch HSTS womöglich aus. Ruft die Oberfläche über die IP-Adresse oder den SSH-Tunnel auf. Läuft Nextcloud, ist ausserdem die Anmeldung mit der Passphrase gesperrt, siehe Schritt 4.

Der Mastercontainer startet keine anderen Container

Dann erreicht er meist den Docker-Socket nicht, etwa bei einer Snap-Installation oder bei Docker ohne Root-Rechte. Die Logs zeigen die Ursache:

sudo docker logs nextcloud-aio-mastercontainer

Hinter Caddy erscheint ein Fehler 502

Der Port im Caddyfile muss exakt dem Wert von APACHE_PORT entsprechen, und APACHE_IP_BINDING muss zu der Adresse passen, über die Caddy AIO anspricht. Läuft Caddy selbst in einem Container, prüft ihr aus diesem heraus mit nc -z localhost 11000; echo $?, ob der Port erreichbar ist. Eine 0 bedeutet ja.

Von zu Hause aus lädt die Domain nicht

Von unterwegs geht es, im WLAN nicht: Das ist fast immer fehlendes Hairpin NAT. Abhilfe schafft ein lokaler DNS-Eintrag, siehe den Abschnitt zu deSEC und zum LAN-Zugriff.

Ihr wollt ganz von vorne anfangen

Ging beim ersten Einrichten so viel schief, dass ein Neuanfang einfacher ist, beschreibt das Projekt im FAQ unter „How to properly reset the instance?“ den vollständigen Ablauf. Achtung: Dabei werden alle Container, das Netzwerk und alle Volumes von AIO gelöscht, also auch eure Daten. Das ist nur für eine frische Installation gedacht, nie für eine Instanz, auf der schon Dateien liegen.

Fazit: AIO nimmt euch die Installation ab, nicht die Verantwortung

Nextcloud AIO ist der kürzeste Weg zu einer vollständigen, sauber konfigurierten Nextcloud auf eigener Hardware. Datenbank, Cache, Zertifikat, Push-Dienst und Updates kommen aus einer Hand, und wer früher eine Nextcloud von Hand installiert hat, weiss, wie viele Abende das spart.

Abgenommen wird euch aber nur das Aufsetzen. Ob Port 8080 offen im Internet hängt, weil Docker die Firewall elegant übergeht, ob der Borg-Schlüssel ausserhalb des Servers liegt und ob es eine zweite Kopie an einem anderen Ort gibt, entscheidet ihr. Ebenso, ob ihr dem Mastercontainer den Docker-Socket und damit faktisch den ganzen Server anvertraut. Eine eigene Cloud ist frei von Google und Microsoft, aber nicht frei von Pflege. Sie ist das, was Google Drive nie sein wollte: eure Sache.

Quellen und weiterführende Links

• Nextcloud All-in-One: readme.md mit Installationsanleitung und FAQ (GitHub)
• Nextcloud All-in-One: Reverse-Proxy-Dokumentation (GitHub)
• Nextcloud All-in-One: offizielle compose.yaml (GitHub)
• Nextcloud All-in-One: Betrieb im lokalen Netz (GitHub)
• Nextcloud All-in-One: Installation ohne Docker-Socket (GitHub)
• Docker: Install Docker Engine on Debian
• Docker: Install Docker Engine on Ubuntu
• Docker: Packet filtering and firewalls
• Docker: Port publishing and mapping
• Docker: Docker Engine security
• BorgBackup (GitHub)
• deSEC: kostenloser DNS-Dienst

The post Nextcloud AIO installieren: eigene Cloud mit Docker appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Für die meisten Server ist das kein Drama, sofern die Erneuerung wirklich automatisch läuft. Für alle, bei denen irgendwo eine feste Zahl in einem Cronjob steht, ist es eine Frist. Diese Meldung sortiert, was sich wann ändert, welche verbreiteten ACME-Programme damit klarkommen und wo es eng wird.

Let's Encrypt 64 Tage: die Termine im Überblick

Ganz neu ist der Plan nicht. Bereits am 2. Dezember 2025 hatte Let's Encrypt den Weg von 90 auf 45 Tage angekündigt, mit einem Zwischenschritt über 64 Tage. Neu ist, dass die Termine jetzt verbindlich bestätigt sind und der Testbetrieb deutlich früher beginnt als damals in Aussicht gestellt. Die Daten im Einzelnen:

• Seit 13. Mai 2026: Wer will, kann über das Profil tlsserver bereits 45 Tage gültige Zertifikate beziehen. Das ist freiwillig und für Frühstarter gedacht.
• 14. Oktober 2026: Die Testumgebung (Staging) stellt auf 64-Tage-Zertifikate um, und zwar mit genau dem Verhalten, das ab Februar in der Produktion gilt. Das bestätigt ein Mitarbeiter von Let's Encrypt im Community-Forum.
• 10. Februar 2027: Das Standardprofil classic liefert nur noch 64 Tage. Gleichzeitig sinkt die Zeit, während der eine erfolgreiche Domainprüfung wiederverwendet werden darf, von 30 auf 10 Tage.
• Um den 11. Mai 2027: Das letzte 90-Tage-Zertifikat läuft voraussichtlich ab. Gültige Zertifikate werden laut Let's Encrypt im Zuge der Umstellung nicht widerrufen.
• 16. Februar 2028: Das Standardprofil sinkt auf 45 Tage, die Wiederverwendung einer Domainprüfung auf sieben Stunden.

Unverändert bleiben nach Angaben von Let's Encrypt die Rate Limits, die ACME-Adressen und die Zertifikatskette. Zu den Rate Limits hatte Let's Encrypt schon im Februar einen eigenen Beitrag veröffentlicht: Erneuerungen zählen nicht auf die Grenzen für neue Zertifikate, also ändert die häufigere Erneuerung daran nichts.

Was gegenüber Dezember neu ist

Im Dezember hiess es noch, jede Änderung erreiche die Testumgebung etwa einen Monat vor der Produktion. Jetzt sind es fast vier Monate. Das ist die eigentlich nützliche Nachricht dieser Woche: Wer seine Erneuerung, seine Reload-Skripte und seine Überwachung gegen echte 64-Tage-Zertifikate prüfen will, kann das ab dem 14. Oktober tun und muss nicht bis Januar warten. Ausserdem nennt die Mitteilung zum ersten Mal ein konkretes Ablaufdatum für die letzten 90-Tage-Zertifikate.

Warum die Zertifikate kürzer werden

Let's Encrypt handelt nicht aus eigenem Antrieb. Im April 2025 hat das CA/Browser Forum, in dem sich Zertifizierungsstellen und Browserhersteller auf gemeinsame Regeln einigen, den Antrag SC081v3 angenommen. Er senkt die höchstzulässige Laufzeit öffentlich vertrauter Zertifikate schrittweise von 398 auf 47 Tage und die Wiederverwendung einer Domainprüfung von 398 auf 10 Tage. Begonnen hat das im März 2026, abgeschlossen ist es im März 2029. Die Zwischenschritte fasst der DNS-Anbieter DNSimple übersichtlich zusammen: höchstens 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Alle vier grossen Browserhersteller, Apple, Google, Microsoft und Mozilla, haben zugestimmt, keine Zertifizierungsstelle hat dagegen gestimmt.

Die Begründung ist nüchtern. Ein Zertifikat, dessen Schlüssel gestohlen wurde, bleibt bis zu seinem Ablauf gültig, wenn der Widerruf nicht greift, und der Widerruf greift in der Praxis schlecht. Je kürzer die Laufzeit, desto kürzer das Zeitfenster für Missbrauch. Let's Encrypt schreibt dazu im Dezemberbeitrag, kürzere Laufzeiten begrenzten den Schaden einer Kompromittierung und machten den Widerruf wirksamer.

Bemerkenswert ist das Tempo. Let's Encrypt lag mit 90 Tagen schon immer weit unter den Branchenregeln und bleibt das auch: Die 64 Tage greifen einen Monat, bevor die 100-Tage-Grenze überhaupt in Kraft tritt. Kommerzielle Anbieter, die früher Jahreszertifikate verkauften, mussten schon im März 2026 auf 200 Tage herunter und dürfen ihren Kunden ab März 2027 erklären, warum das Produkt nach 100 Tagen erneuert werden muss. Das ist allerdings nicht euer Problem.

Wann certbot, acme.sh und Caddy erneuern

Ob die Umstellung euch etwas angeht, hängt fast nur davon ab, wie euer ACME-Programm den Erneuerungszeitpunkt bestimmt. Es gibt drei Verfahren: einen festen Abstand vor dem Ablauf, einen Anteil der Laufzeit, oder die Frage an die Zertifizierungsstelle selbst. Für Letzteres gibt es seit Juni 2025 den Standard RFC 9773, ACME Renewal Information (ARI): Der Server nennt dem Client ein Zeitfenster, in dem er erneuern soll. Let's Encrypt bietet ARI seit März 2023 an.

Caddy: erledigt sich selbst

Caddy unterstützt ARI seit Version 2.8 und zieht es zusammen mit Laufzeit und Widerrufsstatus heran, um eine Erneuerung auszulösen. Wer Caddy nach unserer Anleitung zum Caddy Reverse Proxy betreibt, muss nichts ändern.

certbot: die Version entscheidet

Bei certbot kommt es darauf an, welche Fassung eure Distribution mitliefert. Bis Version 3 erneuerte certbot fest 30 Tage vor Ablauf. Version 4.0 vom 8. April 2025 stellte auf ein Drittel Restlaufzeit um, Version 4.1 vom 10. Juni 2025 fragt zusätzlich ARI ab und erneuert bei Let's Encrypt laut Changelog typischerweise nach rund zwei Dritteln der Laufzeit.

Debian 12 liefert certbot 2.1.0, Debian 13 die Version 4.0.0, so steht es im Debian-Paketverfolger. Ubuntu 24.04 hat certbot 2.9.0. Alle drei kommen mit 64 Tagen zurecht: Die alte 30-Tage-Regel erneuert ein 64-Tage-Zertifikat nach 34 Tagen, die Drittel-Regel nach rund 43 Tagen. Auch bei 45 Tagen im Jahr 2028 bleibt genug Puffer. Wer certbot mit dem vom Paket mitgelieferten Timer betreibt, ist also auf der sicheren Seite, solange niemand die Vorgabe mit einem eigenen renew_before_expiry verbogen hat.

acme.sh: hier wird es eng

Anders sieht es beim reinen Shell-Skript acme.sh aus. Laut der Handbuchseite in Debian 13 erneuert acme.sh standardmässig 60 Tage nach der Ausstellung, gesteuert über --days. ARI beherrscht es noch nicht, das schreibt der Hauptentwickler selbst in Issue 6633 und empfiehlt dort für kurzlebige Zertifikate, --days von Hand anzupassen.

Durchgerechnet bleiben bei einem 64-Tage-Zertifikat noch vier Tage zwischen dem ersten Erneuerungsversuch und dem Ablauf. Das reicht, solange nichts schiefgeht. Fällt die Erneuerung über ein langes Wochenende aus, weil der DNS-Anbieter klemmt oder Port 80 kurz zu ist, steht das Zertifikat abgelaufen da. Ab 2028, mit 45 Tagen, kommt der Erneuerungsversuch nach 60 Tagen schlicht zwei Wochen zu spät. Wer acme.sh nutzt, setzt --days deshalb jetzt auf einen Wert um 40, für jedes Zertifikat einzeln.

Dass es auch anders geht, zeigt pfSense: Das ACME-Paket dort hatte dasselbe Problem mit einem festen 60-Tage-Abstand und erneuert seit Version 1.1 standardmässig nach zwei Dritteln der Laufzeit. Das Paket ist für pfSense Plus 25.11.1 und CE 2.8.1 erschienen.

Selbst geschriebene Skripte und Cronjobs

Die grösste Gefahr steckt nicht in den bekannten Programmen, sondern in Eigenbauten: dem Skript, das alle 60 Tage --force-renewal auslöst, oder dem Überwachungscheck, der erst bei 80 Tagen Alter Alarm gibt. Let's Encrypt rät ausdrücklich dazu, Cronjobs, Hilfsskripte und Betriebsanleitungen nach typischen fest eingetragenen Werten wie 83, 80 oder 60 zu durchsuchen. Ein Skript, das erst nach 80 oder 83 Tagen erneuert, kommt bei 64 Tagen schlicht zu spät. Ohne ARI empfiehlt Let's Encrypt, nach ungefähr zwei Dritteln der Laufzeit zu erneuern.

Eine Sache, die viele noch im Kopf haben, gibt es übrigens nicht mehr: die Warn-E-Mail vor dem Ablauf. Let's Encrypt hat diesen Dienst am 4. Juni 2025 eingestellt. Wer sich darauf verlassen hat, ist seit über einem Jahr ohne Netz unterwegs. Auch unsere ältere Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver geht noch davon aus, dass diese Mail kommt.

Die kürzere Wiederverwendung der Domainprüfung

Der zweite Teil der Änderung fällt weniger auf. Bisher durfte Let's Encrypt eine erfolgreiche Domainprüfung 30 Tage lang für weitere Zertifikate wiederverwenden, ab Februar sind es 10 Tage. Wer die Erneuerung voll automatisch erledigt, merkt davon laut Let's Encrypt nichts, ausser der Client ist ausdrücklich darauf gebaut, sich auf die Wiederverwendung zu verlassen. Betroffen sind vor allem Setups mit DNS-Challenge, bei denen der TXT-Eintrag von Hand gesetzt wird. Für sie hat Let's Encrypt im Februar das Verfahren DNS-PERSIST-01 angekündigt, bei dem ein dauerhafter TXT-Eintrag ein bestimmtes ACME-Konto berechtigt. Der Produktivstart war für das zweite Quartal 2026 angepeilt; ob er erfolgt ist, sagt die aktuelle Mitteilung nicht.

Was ihr bis Februar prüfen solltet

Das meiste davon ist eine Sache von zehn Minuten pro Server. Die Reihenfolge ist so gewählt, dass ihr nach dem ersten Punkt bereits wisst, ob der Rest euch überhaupt betrifft.

1. Herausfinden, welcher Client erneuert. Bei certbot zeigt certbot --version die Fassung, bei acme.sh acme.sh --version. Läuft Caddy, ist der Punkt erledigt.
2. Feste Zahlen suchen. Durchsucht Cronjobs und systemd-Units nach Erneuerungsabständen. Ein grober erster Durchgang, der alle Zeilen mit den von Let's Encrypt genannten Werten zeigt:

sudo grep -rnwE '60|80|83' /etc/cron* /etc/systemd/system /var/spool/cron 2>/dev/null

Nicht jeder Treffer hat mit Zertifikaten zu tun, eine Minutenangabe von 60 ist harmlos. Gesucht sind Zeilen, in denen certbot, acme.sh, --days, --force-renewal oder ein eigenes Erneuerungsskript vorkommt.

3. Ab dem 14. Oktober gegen Staging testen. certbot holt mit --dry-run laut Handbuchseite ein Testzertifikat von der Staging-Umgebung, ohne es zu speichern. Das prüft, ob die Challenge durchläuft:

sudo certbot renew --dry-run

4. Die Laufzeit des aktuellen Zertifikats ansehen. So seht ihr, wann es ausgestellt wurde und abläuft. Den Domainnamen ersetzt ihr durch euren:

sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/cloud.example.ch/cert.pem

5. acme.sh umstellen. Setzt --days beim nächsten Ausstellen auf einen Wert um 40, damit auch bei 45 Tagen im Jahr 2028 Puffer bleibt.
6. Eine Ablaufwarnung einrichten, die nicht von Let's Encrypt kommt. Die Mail gibt es nicht mehr. Eine eigene Prüfung per systemd-Timer mit Benachrichtigung bei Fehlschlag haben wir in der Anleitung systemd-Timer statt Cronjob beschrieben; openssl x509 -checkend mit einer Sekundenzahl ist dafür der passende Baustein.
7. Den Reload nicht vergessen. Ein erneuertes Zertifikat nützt nichts, wenn der Webserver weiter das alte ausliefert. Bei certbot erledigt das ein Deploy-Hook, bei Diensten mit eigener Zertifikatskopie (Mailserver, Datenbanken, NAS) muss die Kopie nach jeder Erneuerung neu verteilt werden. Wer nach zwei Dritteln der Laufzeit erneuert, tut das bei 64 Tagen rund achtmal im Jahr statt wie bisher rund sechsmal.

Fazit: 64 Tage bestrafen nur Handarbeit

Für einen sauber automatisierten Server ändert der 10. Februar 2027 nichts, ausser dass im Log etwas öfter eine Erneuerung steht. Caddy, aktuelle certbot-Fassungen und alles, was ARI spricht, regeln das selbst. Selbst die alten certbot-Versionen in Debian 12 und Ubuntu 24.04 kommen mit ihrer starren 30-Tage-Regel durch.

Treffen wird es die Stellen, an denen ein Mensch einmal eine Zahl eingetragen hat und seither niemand mehr hingesehen hat: das acme.sh mit 60 Tagen, das Skript mit erzwungener Erneuerung, das NAS, auf das jemand das Zertifikat von Hand kopiert. Genau darauf zielt die Branche, und es fällt schwer, ihr zu widersprechen. Ein Zertifikat, das ein Jahr hält, verzeiht vergessene Automatisierung; eines, das 64 Tage hält, deckt sie auf. Wer die Testumgebung ab dem 14. Oktober nutzt, findet diese Stellen im Herbst statt an einem Februarmorgen, an dem die Nextcloud plötzlich eine rote Warnseite zeigt.

Quellen und weiterführende Links

• Let's Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027, Ankündigung vom 7. Oktober 2026
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days, Zeitplan vom 2. Dezember 2025
• Let's Encrypt: Profiles, Profile classic, tlsserver und shortlived
• Let's Encrypt: Rate Limits and 45-Day Certificates, Februar 2026
• Let's Encrypt Community: Staging-Termin für die 64-Tage-Zertifikate
• Let's Encrypt: Expiration Notification Service Has Ended
• Let's Encrypt: DNS-PERSIST-01, Ankündigung vom 18. Februar 2026
• Let's Encrypt: Upcoming Features, Stand der Funktionen inklusive ARI
• CA/Browser Forum: Ballot SC081v3, Beschluss und Abstimmungsergebnis
• DNSimple: SSL Certificate Validity Changes (2026–2029), Zwischenschritte des Zeitplans
• RFC 9773: ACME Renewal Information (ARI) Extension
• Certbot 4.0.0 und Certbot 4.1.0, Changelogs zu Erneuerungszeitpunkt und ARI
• Debian-Paketverfolger: python-certbot und Ubuntu-Paket certbot in 24.04
• certbot(1) und acme.sh(1), Handbuchseiten in Debian 13
• acme.sh Issue 6633, Aussage des Entwicklers zu fehlender ARI-Unterstützung
• Caddy v2.8.0 Release Notes, ARI-Unterstützung
• pfSense Redmine 16603, Erneuerung nach zwei Dritteln der Laufzeit im ACME-Paket 1.1

The post Let's Encrypt 64 Tage: kürzere Zertifikate ab 2027 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dieser Kommentar ist keine Abrechnung mit Signal. Er stellt fest, dass Signal technisch vorbildlich ist und organisatorisch eigenwillig, dass der beliebte Ausweg Molly gerade sichtbar ins Stocken gerät, und dass Matrix die offenere Antwort ist — aber keine kostenlose. Wie viel welcher Messenger über euch verrät, haben wir in unserem Beitrag zu Metadaten bei Messengern ausführlich verglichen; das wird hier nicht wiederholt.

Signal oder Matrix: worum es eigentlich geht

Zuerst das, was an Signal unstrittig ist. Die Verschlüsselung ist der Massstab, an dem sich andere messen lassen müssen, und die Architektur ist auf Datensparsamkeit gebaut. Wie konsequent das ist, zeigt Signal selbst auf einer eigenen Seite mit allen Behördenanfragen: Die einzigen Daten, die Signal herausgeben kann, sind laut eigener Aussage der Zeitpunkt der Registrierung und der Tag der letzten Verbindung. Die Liste reicht von einer Grand-Jury-Vorladung 2016 bis zu einer weiteren in diesem Jahr, und jedes Mal steht dort dasselbe.

Genau deshalb ist die Kritik an Signal so schwer zu führen. Wer Signal wegen der Verschlüsselung angreift, liegt falsch. Die Reibung entsteht an anderer Stelle: bei Entscheidungen, die eine einzelne Organisation für Millionen von Nutzern trifft, ohne sie offen zu begründen — beim Geld, bei der Verteilung über Google, beim Push-Dienst und beim Umgang mit allem, was nicht von Signal selbst kommt. Das sind keine Sicherheitslücken. Es sind Abhängigkeiten.

Das Geld: öffentlich, aber nicht durchschaubar

Der Vorwurf der „unklaren Finanzierung" stimmt nur zur Hälfte, und die Hälfte, die nicht stimmt, gehört an den Anfang. Signal ist eine gemeinnützige Stiftung nach US-Recht und muss jährlich eine Steuererklärung veröffentlichen. ProPublica führt diese Formulare für die Signal Technology Foundation lückenlos ab 2018. Wer wissen will, wie viel Signal einnimmt und ausgibt, kann es nachlesen. Das ist mehr, als die meisten kommerziellen Messenger je offenlegen.

Was die Zahlen zeigen

Gelesen ergeben diese Zahlen allerdings ein unruhiges Bild. Für das Geschäftsjahr 2024 weist die Stiftung Einnahmen von rund 29,4 Millionen Dollar aus, davon 21,8 Millionen aus Zuwendungen, dem stehen Ausgaben von 38,0 Millionen gegenüber. Das Nettovermögen ist negativ, bei minus 4,7 Millionen. Auch 2021 und 2022 lagen die Ausgaben deutlich über den Einnahmen. Signal selbst hat das nie verschwiegen: Im Beitrag „Privacy is Priceless, but Signal is Expensive" vom November 2023 rechnete die Organisation vor, dass sie bis 2025 rund 50 Millionen Dollar pro Jahr brauchen werde, davon etwa 14 Millionen für Infrastruktur und rund 19 Millionen für die etwa 50 Angestellten.

Am Anfang steht ein Darlehen. Signal nennt es selbst ein „generous initial loan from Brian Acton", dem WhatsApp-Mitgründer. Laut den Steuerformularen lagen die Verbindlichkeiten der Stiftung Ende 2018 bei 105 Millionen Dollar, ein Jahr später bei 38 Millionen. Was mit der Differenz geschah — ob ein Teil erlassen, umgewandelt oder anders verbucht wurde —, geht aus der Übersicht nicht hervor, und Signal hat es nach unserem Kenntnisstand nie in einem eigenen Beitrag erklärt. Das ist kein Skandal. Aber es ist genau die Art Lücke, in der Spekulationen gedeihen.

Woher die Spekulationen kommen

Die hartnäckigste Erzählung lautet, Signal sei ein Projekt der US-Regierung. Ihr wahrer Kern: Der Open Technology Fund, nach eigener Darstellung „funded through annual appropriations passed by the United States Congress", hat Open Whisper Systems, den Vorläufer der heutigen Stiftung, zwischen 2013 und 2016 mit insgesamt 2.955.000 Dollar gefördert. Daraus wird in Foren regelmässig eine Hintertür. Belegt ist davon nichts: Der Quellcode ist offen, die Builds sind seit 2016 reproduzierbar, und die Behördenanfragen sprechen eine deutliche Sprache.

Die zweite Episode ist hausgemacht. Im April 2021 baute Signal Zahlungen mit der Kryptowährung MobileCoin ein. Bruce Schneier hielt das damals für einen Fehler: Es lade Steuer-, Finanz- und Ermittlungsbehörden geradezu ein, und es gebe „no good reason to tie the two functions together in a single product". In einem Nachtrag wies er darauf hin, dass Signal-Gründer Moxie Marlinspike im Beirat von MobileCoin sass. Eine Organisation, die von Vertrauen lebt, hat damit einen Interessenkonflikt selbst ins Haus geholt. Wer danach jede Finanzfrage mit Misstrauen stellt, ist nicht paranoid, sondern hat aufgepasst.

Kein F-Droid, kein Unified Push, keine Föderation

Der zweite Punkt betrifft Leser dieses Blogs unmittelbar, denn er entscheidet darüber, wie Signal auf einem Telefon ohne Google läuft. Signal empfiehlt den Play Store ausdrücklich als „safest and easiest way". Die APK zum direkten Herunterladen gibt es zwar, aber mit dem Satz, normale Nutzer sollten das „under normal circumstances" nicht tun. Eine Fassung in F-Droid gibt es nicht. Moxie Marlinspike schrieb 2017, im Forum von F-Droid zitiert: „I have no plans to distribute this through f-droid, and don't see what the advantage of doing so would be."

Beim Push-Dienst ist es ähnlich. Signal setzt auf Googles Firebase Cloud Messaging, kurz FCM, und ohne Google-Dienste auf eine eigene, dauerhaft offene WebSocket-Verbindung; die Hilfeseite zu Benachrichtigungen nennt beides als Fehlerquelle. Was das für Akku und Privatsphäre bedeutet, haben wir in Was ist Google Push beschrieben. Unified Push, das offene Gegenmodell, unterstützt Signal nicht. In der Liste der Apps mit Unified Push taucht Signal nicht auf, wohl aber Molly und mehr als zehn Matrix-Clients. Eine öffentliche Begründung von Signal, warum nicht, haben wir nicht gefunden.

Das Muster dahinter ist alt und gut dokumentiert. Als 2016 das Projekt LibreSignal ohne Google-Abhängigkeit mit Signals Servern sprechen wollte, antwortete Marlinspike laut LWN: „You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run." Und: „It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult." Das ist eine ehrliche, technisch begründbare Position. Sie heisst aber auch: Signal entscheidet allein, wie ihr Signal benutzen dürft, und es fühlt sich nicht verpflichtet, darüber zu verhandeln.

Zur Fairness gehört, dass Signal sich bewegt, wenn es will. Seit September testet die Organisation laut Android Authority in der Beta 8.28.1 eine Registrierung ganz ohne Telefonnummer, gegen eine einmalige Gebühr von drei Dollar, die über Zero-Knowledge-Nachweise vom Konto getrennt bleiben soll. Das ist ein echter Fortschritt. Und es ist wieder eine Entscheidung, die niemand ausserhalb von Signal kommen sah.

Molly: der Ausweg, der gerade stottert

Für alle, denen das zu viel Google ist, war Molly mit Unified Push lange die elegante Lösung: ein gehärteter Fork von Signal, mit Passphrase für die Datenbank, ohne Google-Bibliotheken in der FOSS-Fassung und mit Push über MollySocket. Molly spricht mit denselben Servern, eure Kontakte merken keinen Unterschied. Das Projekt verspricht in seiner Beschreibung auf GitHub: „Molly updates every two weeks to include the latest Signal features and fixes."

Zwei Wochen, die zu drei Monaten wurden

Die Release-Liste erzählt eine andere Geschichte. Auf Version 8.7.3 vom April folgte erst Mitte Juli die 8.19.2, gut zwölf Signal-Versionen später. Die bisher letzte Fassung, 8.19.2-4, erschien am 31. Juli. Signal selbst ist seither laut der Release-Übersicht von Releasebot bei Version 8.29 vom 23. September angekommen. Am 1. Oktober schrieb ein Nutzer in Issue 831: „It's been almost 3 months and about 10 Signal releases since the last update again." Das Wort „again" ist das eigentlich Bemerkenswerte.

Drei Tage später folgte Issue 834: Mehrere Geräte mit der aktuellen Molly-Version unter GrapheneOS stellten keine Nachrichten mehr zu, es blieb bei einem Haken, und mit der offiziellen Signal-App funktionierte alles. Bis zum heutigen Tag steht darunter keine Antwort der Entwickler. Auch bei uns melden sich seit einiger Zeit Nutzer mit genau diesem Muster. Neu ist es nicht: Schon im April musste Molly mit 8.7.3-2 eine Fassung nachschieben, die laut Release-Notiz Probleme beim Senden für Nutzer von Unified Push behob.

Woran es diesmal liegt, ist nicht belegt; dazu schweigt das Projekt. Strukturell ist die Ursache aber offensichtlich. Ein Fork, der mit einem fremden, zentral betriebenen Server spricht, muss jede Änderung dieses Servers nachziehen, und zwar in dessen Takt, nicht in seinem eigenen. Signal ändert sein Protokoll, wann es will, und schuldet Molly nichts — das hat Marlinspike 2016 ausdrücklich so gesagt. Ein kleines, unabhängiges Projekt kann dieses Wettrennen eine Weile mithalten. Dauerhaft gewinnen kann es nicht. Und ausgerechnet ein Messenger für Sicherheitsbewusste, der dem Original um zehn Versionen hinterherläuft, ist eine Pointe, über die niemand lachen möchte — selbst wenn Molly verspricht, Sicherheitskorrekturen sofort nachzuziehen.

Zwischenfazit: Signal ist sicher, aber nur zu Signals Bedingungen. Molly hat versucht, diese Bedingungen zu verbessern, und zeigt gerade, warum das auf Dauer nicht trägt. Das liegt nicht an den Entwicklern von Molly, sondern an der Architektur, die Signal bewusst gewählt hat.

Matrix: offen, föderiert, mit eigenen Baustellen

Matrix ist in fast jedem dieser Punkte das Gegenmodell. Es ist ein offenes Protokoll, das jeder auf einem eigenen Server betreiben kann, und es gibt nicht eine App, sondern viele. Die Matrix.org Foundation empfiehlt selbst Element und Element X, FluffyChat, Cinny und Nheko. Unified Push ist dort kein Bastelprojekt: In der Liste von unifiedpush.org stehen unter anderem Element, Element X, FluffyChat und SchildiChat. Wie das mit Element konkret aussieht, zeigt unsere Anleitung Element ohne Google Push. Entscheidet sich ein Client-Projekt für etwas, das euch nicht passt, nehmt ihr einen anderen — ohne euer Konto, eure Kontakte oder euren Server zu wechseln. Genau das kann Molly nicht.

Wer allerdings Signal die Finanzen vorhält und bei Matrix wegschaut, macht es sich zu leicht. Im Februar 2025 schrieb die Foundation in „Crossroads", sie sei „not yet sustainable": 561.000 Dollar Einnahmen standen 2024 Ausgaben von 1,2 Millionen gegenüber, ohne 100.000 Dollar Soforthilfe drohte die Abschaltung der Brücken zu Slack, XMPP und IRC. Der Jahresbericht vom März 2026 meldet Besserung — 38 Prozent mehr Einnahmen, der Verlust sank von 50 auf 34 Prozent der Kosten —, aber auch, dass die Hälfte der Einnahmen von einem einzigen Mitglied stammt, Automattic, und dass die Foundation „disproportionately dependent on Element's in-kind donations and financial support" sei. Signal hängt an wenigen grossen Gebern. Matrix hängt an einer Firma.

Diese Firma hat bereits einmal gezeigt, dass sie die Regeln ändern kann. Im November 2023 stellte Element den wichtigsten Server, Synapse, von der Apache-Lizenz auf die AGPLv3 um und verlangt seither von neuen Beitragenden eine Lizenzvereinbarung. Für Selbsthoster ändert das wenig, die AGPL ist eine freie Lizenz. Aber es zeigt, dass auch bei Matrix eine Stelle wichtige Entscheidungen allein treffen kann. Der Unterschied zu Signal: Die Spezifikation ist offen, es gibt weitere Server-Implementierungen, und ein Fork bleibt mit dem Rest des Netzes verbunden.

Bleiben die Metadaten, und hier ist Matrix klar schlechter. Jeder beteiligte Homeserver kennt Mitgliedschaften, Zeitpunkte und Gegenstellen eurer Räume. Wie viel genau, steht im Metadaten-Vergleich. Wer seinen eigenen Server betreibt oder einen vertrauenswürdigen Betreiber nutzt, verschiebt dieses Problem dorthin, wo er es kontrolliert. Wer einfach ein Konto auf matrix.org anlegt, hat es dagegen gegen einen anderen zentralen Betreiber eingetauscht. Hier gehört eine Offenlegung hin: Wir betreiben selbst einen öffentlichen Matrix-Server und einen MollySocket-Dienst. Wir haben also an beiden Seiten dieses Vergleichs ein eigenes Interesse, und ihr solltet das wissen.

Die Gegenposition: Zentralisierung ist ein Feature

Das stärkste Argument für Signal stammt von Signal selbst, und es verdient eine ernsthafte Antwort. Marlinspike begründete die Absage an Föderation damit, dass ein föderiertes Protokoll kaum noch zu ändern sei, weil alle Server mitziehen müssten. Ein zentraler Dienst kann dagegen über Nacht eine neue Verschlüsselung ausrollen, Sealed Sender einführen oder Telefonnummern optional machen. Matrix kennt das Gegenteil: Neue Funktionen hängen an Spezifikationsvorschlägen und an Homeservern, die sie umsetzen müssen.

Das Argument stimmt — für die Technik. Für die Organisation dreht es sich um. Dieselbe Zentralisierung, die schnelle Verbesserungen erlaubt, erlaubt auch schnelle Fehlentscheidungen wie den MobileCoin-Ausflug, und sie macht jede Abhängigkeit, ob von Google, von einem Darlehen oder von einer Handvoll Grossspendern, zu einer Abhängigkeit aller Nutzer. Dass Signal diese Macht bisher überwiegend im Sinne seiner Nutzer eingesetzt hat, ist ein Verdienst der handelnden Personen. Eine Garantie ist es nicht.

Auch die Absage an F-Droid lässt sich so begründen, und Marlinspike tat es mit dem Satz, er sehe keinen Vorteil darin. Der Vorteil liegt allerdings auf der Hand, nur nicht für Signal: Wer F-Droid nutzt, braucht weder ein Google-Konto noch den Play Store, um Updates zu bekommen. Ausgerechnet die reproduzierbaren Builds, die Signal seit 2016 anbietet, wären die ideale Grundlage für eine überprüfbare Fassung aus einer zweiten Quelle. Dass Signal darauf verzichtet, ist kein Sicherheitsargument. Es ist eine Frage der Kontrolle über den Verteilweg — und die will Signal nicht teilen.

Das zweite Gegenargument lautet, Matrix sei für normale Menschen zu kompliziert. Das ist leiser geworden, seit Element X und FluffyChat sich wie gewöhnliche Messenger bedienen lassen, aber es ist nicht falsch: Wer zwischen Homeservern wählen, Schlüssel sichern und Geräte verifizieren muss, hat mehr zu tun als bei Signal. Diese Arbeit ist der Preis der Unabhängigkeit. Wer sie nicht leisten will, ist bei Signal besser aufgehoben als bei einem schlecht betreuten Matrix-Konto.

Signal, Molly oder Matrix: was das für euch heisst

Eine Antwort für alle gibt es nicht, aber es gibt klare Fälle.

• Ihr nutzt ein Telefon mit Google-Diensten oder GrapheneOS mit Sandboxed Google Play: Bleibt bei der offiziellen Signal-App. Ihre Kryptografie ist unbestritten, und die Abhängigkeit von FCM habt ihr dort ohnehin.
• Ihr nutzt Molly und es läuft: Behaltet im Auge, wie weit Molly hinter Signal liegt. Zehn Versionen Rückstand sind ein Warnzeichen, auch wenn Molly verspricht, Sicherheitskorrekturen sofort zu übernehmen. Ein Backup der Chats vor jedem grösseren Sprung ist Pflicht.
• Molly stellt nicht mehr zu: Der kurzfristige Ausweg ist die offizielle Signal-App als APK, die ohne Google-Dienste über WebSocket statt FCM arbeitet. Sie spricht mit denselben Servern, das Konto registriert ihr mit derselben Nummer neu, und die Chats kommen über ein Backup mit — Molly bezeichnet seine Sicherungen als kompatibel mit Signal. Das kostet etwas Akku, funktioniert aber.
• Euch geht es um Unabhängigkeit, nicht nur um Verschlüsselung: Dann ist Matrix die konsequentere Wahl, am besten auf einem eigenen oder einem vertrauten Homeserver und mit einem Client, der Unified Push kann. Rechnet mit mehr Metadaten beim Server und mit etwas mehr Aufwand.
• Euer Umfeld ist auf Signal: Dann bleibt Signal der Messenger, über den ihr eure Leute erreicht. Matrix ersetzt Signal nicht über Nacht, es kann neben ihm wachsen — für Gruppen, Familien und Projekte, die ihre Infrastruktur selbst in der Hand haben wollen.

Fazit: Signal ist sicher, aber nicht eures

An Signal ist nichts faul. Die Verschlüsselung hält, die Datensparsamkeit ist belegt, und die Finanzen liegen offener auf dem Tisch als bei fast jedem anderen Messenger. Merkwürdig wird Signal erst, wenn ihr fragt, wer bestimmt: wie ihr die App bekommt, über welchen Dienst sie euch weckt, ob ein Fork mitspielen darf und wofür das Geld der Stiftung ausgegeben wird. Die Antwort lautet jedes Mal: Signal, und zwar allein.

Molly war der Versuch, die beste Verschlüsselung mit mehr Freiheit zu verbinden, und er zeigt gerade seine Grenze. Matrix bietet diese Freiheit von Grund auf, verlangt dafür aber Mitdenken, einen guten Homeserver und Geduld mit einer Foundation, die selbst noch um ihr Budget kämpft. Das ist der ehrliche Tausch: Bei Signal vertraut ihr einer Organisation, bei Matrix vertraut ihr vor allem euch selbst. Für einen Blog, der Selbsthosting nicht als Hobby versteht, ist die Richtung damit klar — aber wer heute nur sicher chatten will, macht mit Signal nichts falsch.

Quellen und weiterführende Links

• Signal — Government Communication, alle beantworteten Behördenanfragen und die herausgegebenen Daten
• ProPublica Nonprofit Explorer — Signal Technology Foundation, Form 990 für 2018 bis 2024
• Signal — Privacy is Priceless, but Signal is Expensive, Kostenaufstellung vom 16.11.2023
• Open Technology Fund — Signal / Open Whisper Systems, Förderung 2013 bis 2016
• Open Technology Fund — About, Finanzierung über den US-Kongress
• Signal — Reproducible Signal builds for Android, 31.03.2016
• Bruce Schneier — Signal Adds Cryptocurrency Support, 07.04.2021
• Signal — Android APK, Empfehlung des Play Store und Warnhinweis zur direkten Installation
• F-Droid Forum — Signal: Discussion about Google Play alternative, Zitat von Moxie Marlinspike vom 14.03.2017
• Signal Support — Notifications, Play-Dienste und WebSocket als Fehlerquellen
• UnifiedPush — Apps using UnifiedPush, Liste der unterstützenden Apps
• LWN — The perils of federated protocols, LibreSignal und Marlinspikes Absage an Föderation, 18.05.2016
• Android Authority — Signal will let you register without a phone number, 17.09.2026
• Molly auf GitHub, Projektbeschreibung und Update-Versprechen
• Molly — Releases, Versionen und Release-Notizen
• Molly Issue 831 — No updates, 01.10.2026
• Molly Issue 834 — Problems with Molly users messages today, 04.10.2026
• Releasebot — Signal Android Updates, Versionsübersicht von Signal für Android
• Matrix.org — Try Matrix, empfohlene Clients
• Matrix.org — The Matrix.org Foundation is at a crossroads, 20.02.2025
• Matrix.org — Annual Report 2025, 27.03.2026
• Element — A new home and license (AGPL) for Synapse and friends, 06.11.2023

The post Signal oder Matrix: warum Signal merkwürdig bleibt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung baut direkt auf unserer Einrichtung des Caddy Reverse Proxy mit automatischem HTTPS auf; Installation, Caddyfile und Zertifikate für den Server setzen wir voraus. Hier kommt die andere Richtung dazu: Nicht nur der Server weist sich gegenüber eurem Gerät aus, sondern auch euer Gerät gegenüber dem Server. Dafür legen wir mit OpenSSL eine eigene kleine Zertifizierungsstelle an, stellen jedem Gerät ein Zertifikat aus, bringen Caddy bei, nur noch diese zu akzeptieren, und klären, wie ihr ein verlorenes Gerät wieder aussperrt.

mTLS mit Caddy: was gegenseitiges TLS leistet

Bei gewöhnlichem HTTPS ist die Prüfung einseitig. Der Server zeigt ein Zertifikat vor, euer Browser prüft es, und danach steht eine verschlüsselte Verbindung — zu irgendwem. Bis zum Login hat jeder Besucher Zugriff auf alles, was davor liegt: Anmeldemaske, öffentliche Schnittstellen und jede Sicherheitslücke, die genau dort steckt.

Mutual TLS, kurz mTLS, macht die Prüfung gegenseitig. Während des TLS-Handshakes fordert der Server zusätzlich ein Zertifikat vom Client an und prüft, ob es von einer Stelle unterschrieben ist, der er vertraut. Fehlt es oder stammt es von einer fremden Stelle, endet die Verbindung, bevor eine einzige HTTP-Anfrage ausgewertet wird. Das Anmeldeformular bleibt, steht aber hinter einer zweiten Tür, die sich nur für Geräte öffnet, die ihr selbst ausgestattet habt.

Wichtig ist die Abgrenzung zu einem Verfahren, das wir schon beschrieben haben. Die SSH-Zertifikate aus unserer SSH-CA-Anleitung folgen derselben Idee, benutzen aber ein eigenes OpenSSH-Format ohne jede Verbindung zu X.509. Hier geht es um X.509-Zertifikate, also dasselbe Format, das auch euer Server für HTTPS vorzeigt. Eine SSH-CA lässt sich für mTLS nicht weiterverwenden, und umgekehrt.

Warum es eine eigene Zertifizierungsstelle sein muss

Die naheliegende Frage lautet, ob sich nicht einfach Let's Encrypt einspannen lässt. Die Antwort ist seit diesem Sommer endgültig nein. Let's Encrypt hat im Mai 2025 angekündigt, die Verwendung für Client-Authentifizierung aus seinen Zertifikaten zu streichen: Das Standardprofil verlor sie am 11. Februar 2026, und am 8. Juli 2026 wurde auch das Übergangsprofil tlsclient eingestellt. Als Grund nennt das Projekt die Vorgabe des Chrome-Root-Programms, Server- und Client-Authentifizierung bis Juni 2026 in getrennte Infrastrukturen aufzuteilen. Gleich dazu steht der Hinweis, viele Anwendungsfälle seien mit einer privaten Zertifizierungsstelle ohnehin besser bedient.

Für euren Zweck ist das sogar der bessere Weg. Ein öffentliches Zertifikat beweist nur, dass jemand eine Domain kontrolliert, und das kann jeder. Eine eigene Zertifizierungsstelle beweist, dass ihr dieses Gerät persönlich ausgestattet habt. Genau diese Aussage soll Caddy prüfen. Dass ein Weltkonzern seine Wurzelzertifikate neu sortiert und dabei zufällig das Richtige für Selfhoster herauskommt, ist selten genug, um es einmal festzuhalten.

mTLS oder VPN?

Das gleiche Ziel — nur eigene Geräte kommen an den Dienst — erreicht auch ein VPN, etwa ein eigener Wireguard-Server. Der Unterschied liegt in der Ebene. Ein VPN öffnet einen Tunnel ins Netz, und hinter dem Tunnel ist dann alles erreichbar, was dort freigegeben ist. mTLS gilt pro Dienst und pro Hostname, und auf dem Gerät muss nichts laufen ausser dem Browser oder der App, die ohnehin benutzt wird.

Ein VPN ist die richtige Wahl für Verwaltungsoberflächen, die gar nicht öffentlich sein sollen. mTLS passt dort, wo ein Dienst bewusst im Internet steht, weil Familie oder Freunde ihn ohne VPN-Client nutzen sollen.

Was ihr für die Client-Zertifikate braucht

• Einen laufenden Caddy in Version 2.11.1 oder neuer. Älteren Fassungen fehlt eine Sicherheitskorrektur, die genau diese Funktion betrifft; mehr dazu in Schritt 3. Die aktuelle Version zeigt caddy version.
• OpenSSL auf dem Rechner, der die Zertifizierungsstelle verwahrt. Unter Debian und Ubuntu ist es vorinstalliert. Die Befehle unten wurden mit OpenSSL 3 geprüft.
• Einen sicheren Ort für den privaten Schlüssel der Zertifizierungsstelle. Das ist nicht der Server, auf dem Caddy läuft. Ein verschlüsselter Arbeitsrechner oder USB-Stick genügt.
• Einen zweiten Zugang zum Server, etwa eine offene SSH-Sitzung. Sonst sperrt euch ein Tippfehler aus.

Schritt 1: Eine eigene Zertifizierungsstelle anlegen

Die Zertifizierungsstelle, kurz CA, ist bei OpenSSL ein Schlüsselpaar und ein selbst unterschriebenes Zertifikat. Erzeugt wird beides auf dem Rechner, auf dem es dauerhaft bleiben soll:

mkdir -p ~/client-ca && chmod 700 ~/client-ca
cd ~/client-ca

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out client-ca.key
chmod 600 client-ca.key

openssl req -x509 -new -key client-ca.key -sha256 -days 3650 \
  -subj "/CN=Heimnetz Client-CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out client-ca.crt

Der erste Befehl erzeugt einen Schlüssel auf der Kurve P-256, der zweite daraus ein zehn Jahre gültiges Zertifikat. Die Optionen sind in openssl-req(1) beschrieben: -x509 erzeugt direkt ein Zertifikat statt einer Anfrage, und -addext fügt eine Erweiterung hinzu, in derselben Schreibweise wie in einer Konfigurationsdatei.

Die beiden Erweiterungen sind der eigentliche Inhalt. basicConstraints mit CA:TRUE erklärt das Zertifikat zur Zertifizierungsstelle, und pathlen:0 bedeutet laut x509v3_config(5), dass sie nur Endzertifikate unterschreiben darf, keine weiteren Zwischenstellen. keyUsage beschränkt den Schlüssel auf das Signieren von Zertifikaten und Sperrlisten. Prüft das Ergebnis:

openssl x509 -in client-ca.crt -noout -subject -enddate -ext basicConstraints,keyUsage

Die Datei client-ca.crt ist öffentlich und wandert gleich auf den Server. Die Datei client-ca.key ist das Gegenteil: Wer sie besitzt, kann sich selbst ein Zertifikat für jeden eurer Dienste ausstellen. Für sie gilt dasselbe wie für den CA-Schlüssel aus der SSH-CA-Anleitung — nicht auf den Server, nicht in ein Cloud-Verzeichnis, und eine Kopie an einen zweiten Ort, wie es die 3-2-1-Regel für Backups verlangt. Wer zusätzlich eine Passphrase will, hängt beim ersten Befehl -aes256 an.

Schritt 2: Ein Client-Zertifikat pro Gerät ausstellen

Jedes Gerät bekommt ein eigenes Zertifikat, sonst lässt sich später kein einzelnes Gerät aussperren. Legt zuerst einmalig eine kleine Datei mit den Erweiterungen für Client-Zertifikate an:

cat > ~/client-ca/client.ext <<'EOF'
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
EOF

CA:FALSE verhindert, dass das Gerät selbst Zertifikate ausstellen kann. extendedKeyUsage = clientAuth ist der Eintrag, den x509v3_config(5) als "SSL/TLS WWW Client Authentication" beschreibt — genau der, den Let's Encrypt gestrichen hat. Dann das eigentliche Zertifikat, hier für einen Laptop:

cd ~/client-ca
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out laptop-mario.key
openssl req -new -key laptop-mario.key -subj "/CN=laptop-mario" -out laptop-mario.csr
openssl x509 -req -in laptop-mario.csr \
  -CA client-ca.crt -CAkey client-ca.key \
  -days 365 -sha256 -extfile client.ext \
  -out laptop-mario.crt
openssl verify -CAfile client-ca.crt laptop-mario.crt

Der Name hinter CN= ist frei wählbar. Nehmt etwas, das Person und Gerät eindeutig benennt; er taucht später in den Protokollen auf und ist das, was ihr beim Sperren sucht. Zur Seriennummer müsst ihr nichts tun: Laut openssl-x509(1) erzeugt OpenSSL eine zufällige, wenn weder -CAserial noch -CAcreateserial angegeben ist und keine Seriennummerndatei existiert. Ohne -days gälte das Zertifikat übrigens nur 30 Tage; ein Jahr ist ein brauchbarer Mittelweg zwischen Sicherheit und Erneuerungsaufwand. Die letzte Zeile muss mit laptop-mario.crt: OK enden.

Browser und Betriebssysteme wollen Schlüssel und Zertifikat in einer gemeinsamen, passwortgeschützten Datei im Format PKCS#12. Die entsteht so:

openssl pkcs12 -export \
  -in laptop-mario.crt -inkey laptop-mario.key \
  -certfile client-ca.crt \
  -name "laptop-mario" \
  -out laptop-mario.p12

OpenSSL fragt nach einem Exportpasswort. Vergebt ein echtes, denn die Datei reist gleich über USB-Stick, Messenger oder E-Mail auf das Gerät. -name setzt laut openssl-pkcs12(1) den Anzeigenamen, den Browser beim Auswählen des Zertifikats zeigen. Verschlüsselt wird standardmässig mit AES-256-CBC. Ältere Programme kennen das unter Umständen nicht; meldet ein Gerät beim Import ein falsches Passwort, obwohl es stimmt, erzeugt die Datei mit dem zusätzlichen Schalter -legacy neu, der auf die älteren Verfahren zurückfällt.

Haltet zum Schluss den Fingerabdruck fest. Ihr braucht ihn in Schritt 6, und zwar genau in dem Moment, in dem das Gerät nicht mehr greifbar ist:

openssl x509 -in laptop-mario.crt -noout -fingerprint -sha256 \
  | cut -d= -f2 | tr -d ':' | tr 'A-F' 'a-f' \
  | sed 's/^/laptop-mario /' >> ~/client-ca/register.txt

Die Umformung in Kleinbuchstaben ohne Doppelpunkte ist kein Zierrat: In genau dieser Schreibweise gibt Caddy den Fingerabdruck aus, und nur so passt er später in die Sperrregel. Die Dateien .key, .csr und .p12 des Geräts könnt ihr nach dem Import auf dem Gerät löschen; aufbewahrt werden nur das Zertifikat und das Register.

Schritt 3: Caddy verlangt das Client-Zertifikat

Auf den Server gehört ausschliesslich das öffentliche CA-Zertifikat. Legt es dort ab, wo Caddy es lesen kann:

scp ~/client-ca/client-ca.crt benutzer@server:/tmp/
ssh benutzer@server
sudo install -o root -g caddy -m 0644 /tmp/client-ca.crt /etc/caddy/client-ca.crt

Im Site-Block des Dienstes bekommt die tls-Direktive einen Unterblock client_auth:

cloud.example.ch {
	tls {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/client-ca.crt
		}
	}
	reverse_proxy 127.0.0.1:8080
}

trust_pool file nennt die Datei mit dem CA-Zertifikat, gegen das geprüft wird. mode legt fest, wie streng Caddy dabei ist. Die Dokumentation kennt vier Stufen:

• request — fragt nach einem Zertifikat, lässt aber auch ohne durch und prüft keines.
• require — verlangt ein Zertifikat, prüft aber nicht, von wem es stammt.
• verify_if_given — lässt auch ohne Zertifikat durch, prüft aber jedes, das vorgezeigt wird.
• require_and_verify — verlangt ein gültiges Zertifikat und prüft es.

Für den Schutz eines ganzen Dienstes ist nur die letzte Stufe sinnvoll. Ist ein trust_pool gesetzt, ist sie laut Dokumentation ohnehin die Vorgabe; ohne trust_pool fällt Caddy auf require zurück, und dann genügt irgendein Zertifikat. Schreibt die Zeile trotzdem hin, damit niemand raten muss. Danach wie gewohnt:

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

Testen, bevor ihr den Browser bemüht

Am schnellsten prüft ihr das Ergebnis mit curl von einem Rechner, auf dem Zertifikat und Schlüssel liegen. Drei Aufrufe, drei erwartete Ergebnisse:

# ohne Zertifikat: Verbindung muss scheitern
curl -sS https://cloud.example.ch/

# mit Zertifikat: Antwort des Dienstes
curl -sS --cert laptop-mario.crt --key laptop-mario.key https://cloud.example.ch/

# mit einem selbst gebauten fremden Zertifikat: muss ebenfalls scheitern
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout fremd.key -out fremd.crt -subj "/CN=fremd" -days 1
curl -sS --cert fremd.crt --key fremd.key https://cloud.example.ch/

Ohne Zertifikat meldet curl einen TLS-Abbruch mit certificate required, beim fremden Zertifikat unknown ca. Genau so soll es aussehen. Nur der mittlere Aufruf darf eine Antwort des Dienstes liefern. Lasst den dritten Test nicht weg: Nur er zeigt, dass Caddy wirklich gegen eure CA prüft.

Warum die Version zählt

Ende Februar 2026 wurde in Caddy eine Lücke geschlossen, die genau diesen Aufbau betrifft. Laut dem Sicherheitshinweis GHSA-hffm-g8v7-wrv7 (CVE-2026-27586) haben zwei verschluckte Fehlermeldungen dazu geführt, dass die Client-Authentifizierung "silently fail open", wenn die CA-Datei fehlt, nicht lesbar oder beschädigt ist. Caddy startete dann ohne Warnung und nahm jedes Client-Zertifikat an, das von einer der im System hinterlegten öffentlichen Zertifizierungsstellen stammte. Ein Tippfehler im Pfad hätte den Schutz also lautlos abgeschaltet. Behoben ist das mit Caddy 2.11.1.

Mit einer aktuellen Version sieht derselbe Fehler anders aus: Zeigt trust_pool file auf eine Datei, die es nicht gibt, bricht schon caddy validate mit einer Meldung ab, die den Pfad und no such file or directory nennt. So muss es sein: Ein Fehler in der Konfiguration muss den Start verhindern, nicht den Schutz abschalten. Prüft deshalb mit caddy version, dass ihr nicht auf einer älteren Fassung sitzt, etwa aus dem Paketarchiv einer älteren Distribution.

Ein Snippet für mehrere Dienste

Sollen mehrere Dienste denselben Schutz bekommen, schreibt ihr den Block einmal als Snippet und bindet ihn überall ein. Ein Snippet steht in runden Klammern ausserhalb aller Site-Blöcke:

(mtls) {
	tls {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/client-ca.crt
		}
	}
}

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

fotos.example.ch {
	import mtls
	reverse_proxy 127.0.0.1:2283
}

Eine Eigenheit nimmt euch Caddy dabei von selbst ab. Weil TLS-Einstellungen am Hostnamen aus dem Handshake hängen, die HTTP-Anfrage aber einen eigenen Host-Header mitbringt, könnte ein Client sich mit dem Namen eines ungeschützten Dienstes verbinden und dann einen geschützten anfragen. Die globale Option strict_sni_host verhindert das, und sie ist laut Dokumentation automatisch aktiv, sobald Client-Authentifizierung konfiguriert ist. Wer es ausprobiert, bekommt den Status 421 Misdirected Request.

Schritt 4: Das Client-Zertifikat auf die Geräte bringen

Jetzt braucht jedes Gerät seine .p12-Datei. Übertragt sie auf einem Weg, den ihr kontrolliert, und das Exportpasswort auf einem anderen. Die Bedienschritte unterscheiden sich je nach System:

• Firefox führt einen eigenen Zertifikatsspeicher. Unter Einstellungen, Datenschutz & Sicherheit, Abschnitt Zertifikate, öffnet Zertifikate anzeigen, wechselt auf den Reiter Ihre Zertifikate und wählt Importieren. Die Schritte entsprechen der Importanleitung von DigiCert, die dort für Firefox und Windows beschrieben ist.
• Chrome, Edge und andere Programme unter Windows greifen auf den Zertifikatsspeicher von Windows zu. Ein Doppelklick auf die .p12-Datei startet den Importassistenten; als Ziel wählt ihr den aktuellen Benutzer und den Speicher Eigene Zertifikate.
• Android verwaltet Zertifikate in den Einstellungen unter Sicherheit & Datenschutz, Weitere Sicherheitseinstellungen, Verschlüsselung & Anmeldedaten, Ein Zertifikat installieren; den Pfad beschreibt Google in der Pixel-Hilfe, die Bezeichnungen weichen je nach Hersteller leicht ab. Wählt dort die Variante für VPN- und App-Nutzerzertifikate, wie es etwa die Anleitung des MIT für dessen Client-Zertifikate zeigt — nicht die für CA-Zertifikate.
• Linux auf der Kommandozeile braucht keinen Import. curl nimmt Zertifikat und Schlüssel direkt mit --cert und --key, wie im Test oben.

Beim ersten Aufruf fragt der Browser, welches Zertifikat er vorzeigen soll, und zeigt dabei den Namen aus -name. Danach öffnet sich die gewohnte Anmeldeseite. Prüft auch die App des Dienstes: Nicht jede mobile App kann ein Client-Zertifikat aus dem Systemspeicher vorzeigen, und eine, die es nicht kann, ist ab jetzt ausgesperrt. Testet das, bevor ihr euch unterwegs darauf verlasst.

Schritt 5: Nur den Admin-Bereich hinter das Zertifikat stellen

Manchmal soll der Dienst öffentlich bleiben und nur ein Teil davon geschützt werden, etwa die Verwaltungsoberfläche unter /admin. Eine Einstellung pro Pfad gibt es bei client_auth nicht, weil das Zertifikat im TLS-Handshake abgefragt wird, bevor überhaupt ein Pfad bekannt ist. Der Umweg führt über die mildere Stufe verify_if_given und einen Matcher, der prüft, ob ein Zertifikat vorgezeigt wurde:

vault.example.ch {
	tls {
		client_auth {
			mode verify_if_given
			trust_pool file /etc/caddy/client-ca.crt
		}
	}

	@admin_ohne_zertifikat {
		path /admin*
		vars {tls_client_subject} ""
	}
	respond @admin_ohne_zertifikat "Nur mit Zertifikat" 403

	reverse_proxy 127.0.0.1:8000
}

Der Matcher vars vergleicht den Wert eines Platzhalters, hier {tls_client_subject}, also den Namen aus dem Zertifikat. Ist er leer, wurde keines vorgezeigt, und für Pfade unter /admin gibt es einen 403. Ein vorgezeigtes Zertifikat einer fremden Stelle scheitert schon im Handshake, weil verify_if_given jedes vorgezeigte Zertifikat prüft. Alles ausserhalb von /admin bleibt ohne Zertifikat erreichbar.

Zwei Nebenwirkungen solltet ihr kennen. Erstens fragt Caddy jetzt auf der ganzen Domain nach einem Zertifikat, nicht nur unter /admin; Browser mit installiertem Zertifikat bieten es deshalb auch auf der öffentlichen Seite an. Zweitens schützt dieser Aufbau nur Pfade, die ihr kennt; liegt dieselbe Funktion noch in einer API, bleibt sie offen. Eine eigene Subdomain mit require_and_verify ist deshalb robuster.

Wer ist angemeldet: Zertifikatsdaten an den Dienst weitergeben

Caddy kennt nach dem Handshake die Daten des Client-Zertifikats und stellt sie als Platzhalter bereit. Die Übersicht der Platzhalter nennt unter anderem {tls_client_subject}, {tls_client_issuer}, {tls_client_serial} und {tls_client_fingerprint}. Mit header_up reicht ihr davon weiter, was der Dienst dahinter wissen soll:

cloud.example.ch {
	import mtls
	reverse_proxy 127.0.0.1:8080 {
		header_up X-Client-Subject {tls_client_subject}
	}
}

Der Dienst sieht dann eine Kopfzeile wie X-Client-Subject: CN=laptop-mario, aber nie das Zertifikat oder gar den Schlüssel. In unserem Test mit Caddy 2.11.4 hat Caddy eine vom Client mitgeschickte, gefälschte Kopfzeile gleichen Namens dabei überschrieben. Darauf verlassen darf sich der Dienst trotzdem nur, wenn er ausschliesslich über Caddy erreichbar ist, also an 127.0.0.1 gebunden, wie in der Caddy-Grundanleitung beschrieben. Sonst kann jeder Caddy umgehen und die Kopfzeile selbst setzen.

Schritt 6: Ein Gerät ist weg — Zertifikat sperren

Das klassische Werkzeug zum Widerrufen von X.509-Zertifikaten ist eine Sperrliste. Die Dokumentation der tls-Direktive erwähnt allerdings an keiner Stelle Sperrlisten oder eine andere Widerrufsprüfung für Client-Zertifikate. Verlasst euch also nicht darauf.

Der verlässliche Weg ist eine Sperrregel mit demselben Matcher wie in Schritt 5, gestützt auf den Fingerabdruck aus eurem Register:

(mtls) {
	tls {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/client-ca.crt
		}
	}
	@gesperrt vars {tls_client_fingerprint} 151a598999f66b8a2bf831977b32d6a273ba945734ce0cf3f330fa1954206d93
	respond @gesperrt "Zertifikat gesperrt" 403
}

Der Wert oben ist ein Beispiel; tragt den Fingerabdruck des verlorenen Geräts aus register.txt ein. Weitere gesperrte Geräte hängt ihr mit Leerzeichen getrennt an dieselbe Zeile, denn vars nimmt mehrere Werte und trifft, sobald einer davon passt. Nach caddy validate und systemctl reload caddy bekommt das gesperrte Gerät auf jedem Dienst, der das Snippet einbindet, einen 403. Alle anderen Geräte arbeiten unverändert weiter.

Zur Schreibweise eine Warnung, weil sie Zeit kostet: Caddy liefert den Fingerabdruck in Kleinbuchstaben ohne Doppelpunkte, OpenSSL dagegen in Grossbuchstaben mit Doppelpunkten. Bei der Seriennummer ist es noch tückischer. OpenSSL zeigt sie hexadezimal an, der Platzhalter {tls_client_serial} lieferte in unserem Test dieselbe Zahl in Dezimalschreibweise. Wer eine Seriennummer aus openssl x509 -serial in die Sperrregel kopiert, sperrt deshalb niemanden. Der Fingerabdruck in der Umformung aus Schritt 2 umgeht dieses Problem. Im Zweifel lasst euch den Wert einmal von Caddy selbst ausgeben, etwa mit einem vorübergehenden respond {tls_client_fingerprint}.

Daneben bleibt die Laufzeit das zuverlässigste Sperrmittel, weil sie ohne euer Zutun wirkt. Den Ablauf behaltet ihr am besten mit einer Erinnerung im Blick, etwa über einen systemd-Timer mit Benachrichtigung, der openssl x509 -checkend über die Zertifikate im Register laufen lässt. Und falls der CA-Schlüssel selbst abhandenkommt, hilft keine Sperrregel mehr: Dann legt ihr eine neue CA an, ersetzt client-ca.crt auf dem Server und stattet alle Geräte neu aus.

Wo mTLS an seine Grenzen kommt

Ein Client-Zertifikat schützt den Weg zum Dienst, nicht den Dienst selbst. Wer ein entsperrtes Gerät in der Hand hält, hat das Zertifikat gleich mit. mTLS ergänzt Passwort und zweiten Faktor, es ersetzt sie nicht.

Ausserdem muss die TLS-Verbindung tatsächlich bei Caddy enden. Steht ein fremder Proxy davor, etwa der Proxy-Modus von Cloudflare mit der orangen Wolke, baut Cloudflare die Verbindung zu euren Geräten auf und Caddy sieht nur noch Cloudflare. Ein Client-Zertifikat eures Laptops kommt dort nie an. Für mTLS muss der Eintrag im DNS direkt auf euren Server zeigen.

Und schliesslich will die Absicherung gepflegt werden: Zertifikate laufen ab, Geräte werden ersetzt, neue Familienmitglieder wollen Zugang. Bei drei Geräten ist das wenig Arbeit, bei zwanzig ist ein VPN oder ein Werkzeug, das die Ausstellung automatisiert, die einfachere Antwort. Spätestens wenn die Tabelle mit den Fingerabdrücken länger ist als die Einkaufsliste, ist dieser Punkt erreicht.

Was ihr vorher festlegen solltet

Die Befehle sind in einer Stunde abgearbeitet. Die folgenden Entscheidungen solltet ihr vorher treffen, weil sie sich später nur mühsam ändern lassen:

• Wo der CA-Schlüssel liegt — und wo seine Kopie liegt. Nicht auf dem Server, nicht unverschlüsselt, nicht nur an einem Ort.
• Wie lange Client-Zertifikate gelten. Kürzer heisst sicherer und mehr Arbeit. Ein Jahr ist ein vernünftiger Anfang; für Geräte, die öfter verloren gehen können, darf es weniger sein.
• Nach welchem Schema ihr die Namen vergebt. person-geraet ist im Protokoll lesbar und beim Sperren auffindbar. test2 ist es nicht.
• Wo das Register liegt. Name, Fingerabdruck und Ablaufdatum jedes ausgestellten Zertifikats, an einem Ort, den ihr auch erreicht, wenn das Gerät weg ist.
• Welche Dienste mit welcher Stufe laufen. Ganzer Dienst mit require_and_verify oder nur ein Pfad mit verify_if_given — und ob die zugehörige App überhaupt Client-Zertifikate kann.
• Wie ihr reinkommt, wenn es klemmt. Eine SSH-Sitzung auf den Server oder ein Weg im lokalen Netz, der nicht über den geschützten Dienst führt.

Fazit: mTLS sperrt Fremde aus, bevor sie das Login überhaupt sehen

Ein selbst gehosteter Dienst im Internet ist so sicher wie das, was vor seinem Login liegt. Bei den meisten Installationen ist das nichts: Jeder Scanner der Welt darf die Anmeldeseite abrufen, Benutzernamen durchprobieren und auf die nächste Lücke in genau diesem Code warten. Mit mTLS endet dieser Versuch im Handshake, noch bevor der Dienst davon erfährt. Caddy braucht dafür sechs Zeilen, OpenSSL eine Handvoll Befehle.

Dass Let's Encrypt die Client-Authentifizierung in diesem Jahr gestrichen hat, wirkt auf den ersten Blick wie ein Verlust und ist in Wahrheit eine Klarstellung. Wer bestimmt, welche Geräte an eure Dienste dürfen, gehört nicht in eine öffentliche Zertifizierungsstelle, sondern in euren Schrank. Der Preis dafür ist Verantwortung: für den CA-Schlüssel, für das Register, für die Ablaufdaten. Wer sie übernimmt, hat das stärkste Schloss, das ein Reverse Proxy zu bieten hat — ohne Cloud und ohne irgendjemandes Erlaubnis.

Quellen und weiterführende Links

• Caddy Documentation — tls, Syntax von client_auth, die vier Modi, Vorgabeverhalten und das Modul trust_pool file
• Caddy Documentation — Global Options, strict_sni_host und seine automatische Aktivierung bei Client-Authentifizierung
• Caddy Documentation — Request Matchers, der Matcher vars mit Platzhaltern und mehreren Werten
• Caddy Documentation — Caddyfile Concepts, Platzhalter {tls_client_*}
• Caddy Documentation — reverse_proxy, Kopfzeilen mit header_up setzen
• GHSA-hffm-g8v7-wrv7 / CVE-2026-27586, Client-Authentifizierung schlägt bei fehlender CA-Datei offen fehl
• Caddy v2.11.1 — Release Notes, Behebung von CVE-2026-27586
• Let's Encrypt — Ending TLS Client Authentication Certificate Support in 2026, Zeitplan und Begründung
• openssl-req(1), -x509, -addext, -subj und -days
• openssl-x509(1), Signieren mit -CA, -CAkey und -extfile, zufällige Seriennummer
• x509v3_config(5), basicConstraints, keyUsage und extendedKeyUsage = clientAuth
• openssl-pkcs12(1), Export als PKCS#12, Standardverschlüsselung und -legacy
• DigiCert — Install client authentication certificate in your browser, Import in Firefox und Windows
• Google Pixel-Hilfe — Zertifikate hinzufügen und entfernen, Pfad zu Verschlüsselung & Anmeldedaten
• MIT Knowledge Base — Installing Certificates on Android, Import als VPN- und App-Nutzerzertifikat

The post mTLS mit Caddy: Dienste nur für eigene Geräte appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Timing ist entweder Zufall oder sehr gutes Marketing. Ein Projekt, dem Google gerade die Existenzgrundlage wegverhandelt, veröffentlicht ausgerechnet jetzt seinen modernsten Client. Andere würden das trotzig nennen. Wir nennen es vernünftig.

F-Droid 2.0: was das grosse Update tatsächlich ändert

Laut der Ankündigung des Projekts ist F-Droid 2.0 „a complete redesign of the official F-Droid app and the largest app update in 10 years". Der Client wurde in Kotlin mit Jetpack Compose neu geschrieben, nach mehr als einem Jahr Arbeit und 14 Testversionen. Eine unabhängige Sicherheitsprüfung hat laut F-Droid das Security Lab des Open Technology Fund zusammen mit Convocation durchgeführt; einen veröffentlichten Bericht dazu haben wir nicht gefunden.

Sichtbar wird der Umbau zuerst in der Navigation. Statt der bisherigen Tabs gibt es nur noch drei Bereiche: Entdecken, Suche und Meine Apps. Die Kategorien sind in „Entdecken" aufgegangen und deutlich feiner geworden, allein Spiele zerfallen jetzt in 17 Genres. Die Suche durchsucht neben dem Namen auch Beschreibungen, Kategorien und Übersetzungen. Filter lassen sich kombinieren — nach Kategorie, Gerätekompatibilität und, für unsere Leser wohl am interessantesten, nach Anti-Features. Einstellungen und das Teilen in der Nähe (Nearby Swap) sind über die obere Leiste erreichbar.

Die zweite grosse Änderung ist unsichtbar, aber spürbar: F-Droid 2.0 sucht im Hintergrund nach Updates und installiert sie standardmässig selbst. Wer bisher etwas anderes eingestellt hatte, behält laut Projekt seine Einstellungen; die manuellen Optionen liegen im Menü von „Meine Apps". Das Herunterziehen zum Aktualisieren ist dafür abgeschafft, mit der Begründung: „The best refresh button is the one you never have to press."

Noch nicht bei allen: Basic ja, der klassische Client noch Beta

Wer heute sein F-Droid öffnet und nichts Neues sieht, macht nichts falsch. Das Projekt schreibt ausdrücklich, es beginne damit, die Version „over the coming weeks" an die Nutzer zu verteilen. Den Stand zeigen die Paketseiten:

• Beim klassischen F-Droid-Client ist Stand heute weiterhin 1.23.2 vom 19. Februar 2026 als empfohlene Version markiert. Die Fassungen 2.0.0 vom 23. September und 2.0.1 vom 29. September stehen dort als Beta.
• Bei F-Droid Basic ist 2.0.1 bereits die empfohlene Version. Wer Basic nutzt, hat das Update also vermutlich schon.

Beide Varianten verlangen ab 2.0 mindestens Android 7.0. Was Basic vom klassischen Client unterscheidet und warum wir Basic für die meisten empfehlen, steht in unserer Anleitung zu F-Droid; die Bildschirmfotos dort zeigen allerdings noch die alte Oberfläche.

Installieren wie ein richtiger Store: Session-Installer und Vorabfreigabe

Der technisch wichtigste Teil des Updates ist der neue Installationsweg. F-Droid nutzt jetzt durchgehend Androids Session-Installer und, wo das Gerät es kann, die sogenannte Vorabfreigabe. Das Projekt begründet den Schritt bemerkenswert offen: „Now, thanks largely to pressure from the EU's Digital Markets Act (DMA) and anti-trust actions around the world, Android offers all app stores an option for a smoother and more automatic install and update experience than before."

Was damit gemeint ist, steht in Googles eigener Beschreibung von Android 14: Mit requestUserPreapproval() kann ein Store die Zustimmung des Nutzers einholen, bevor er die App herunterlädt. Bisher kam die Rückfrage erst, wenn das Paket schon auf dem Gerät lag. Ist die Installation einmal freigegeben, kann der Store laut Google „download and install the app in the background without interrupting the user". Auf Geräten ohne diese Schnittstelle fragt Android wie bisher erst nach dem Herunterladen.

Bemerkenswert ist das aus einem Grund, der über F-Droid hinausgeht: Hier hat eine Wettbewerbsregel, die in der Schweiz nicht gilt, eine Systemfunktion erzwungen, die überall ankommt. Dass Regulierung manchmal doch etwas bewirkt, wollen wir in dieser Deutlichkeit festgehalten haben, bevor es wieder jemand bestreitet.

Was wegfällt: Privileged Extension, Panik-Löschen und Android 6

Jede Neuschreibung hat Opfer. Bei F-Droid 2.0 sind es vier, und zwei davon treffen genau die Leute, die F-Droid aus Überzeugung nutzen.

Die Privileged Extension wird nicht mehr benutzt

Die F-Droid Privileged Extension war bisher der Weg, Updates ohne Rückfrage zu installieren, vor allem auf Systemen, die F-Droid fest eingebaut haben. Damit ist Schluss: „F-Droid Privileged Extension (FPE) is not currently supported by 2.0. That means even if FPE is installed, F-Droid 2.0 won't use it." Automatische Updates laufen in 2.0 stattdessen über den Session-Installer. Für Nutzer von Systemen wie CalyxOS, die F-Droid mitliefern, ist das die Änderung, die sie am ehesten bemerken werden.

Panik-Löschen ist vorerst weg

F-Droid konnte bisher auf ein Signal einer Panik-App wie Ripple hin ausgewählte Apps entfernen und ihre Daten löschen. Diese Funktion ist in 2.0 nicht enthalten. Das Projekt begründet das mit dem Wartungsaufwand gemessen an der kleinen Nutzerzahl, nennt sie aber ausdrücklich wichtig und schreibt: „Users who rely on the current app-wiping implementation may opt to postpone updating to F-Droid 2.0 while we evaluate bringing the feature back."

Tor nur noch als Proxy, Android 6 gar nicht mehr

Die automatische Erkennung von Tor ist entfallen, weil sie laut Projekt nicht mehr zuverlässig funktionierte. Wer bisher die Tor-Option („Use Tor") eingeschaltet hatte, findet die Einstellung nach dem Update in den allgemeinen Proxy-Einstellungen wieder. Als einfachsten Weg empfiehlt F-Droid künftig die App Tor VPN, die den Verkehr systemweit durch Tor leitet; wer die Proxy-Einstellungen von Hand pflegt, kann das weiterhin tun, etwa zusammen mit Orbot. Und weil einige der neuen Werkzeuge auf Korrekturen in Android 7 angewiesen sind, fällt Android 6 heraus. Für solche Geräte nennt die Dokumentation zu alten Android-Versionen weiterhin 1.23.2 als passende Fassung.

Alte Kritik, teilweise neue Antworten

Mehrere Punkte aus unserem Beitrag zu den Sicherheitsbedenken bei F-Droid betrafen genau den Client, der jetzt ersetzt wird. Was ist davon übrig?

Damals stand dort, der Client ziele auf API-Level 29 und unterstütze die moderne Update-Schnittstelle von Android nicht. Laut dem Änderungsprotokoll des Clients zielt der neue Client seit 2.0-alpha10 auf target SDK 37, und die Updates laufen über den Session-Installer. Die Privileged Extension, die wir wegen der ungeprüft durchgereichten Berechtigung INSTALL_PACKAGES kritisiert hatten, wird nicht mehr benutzt. Und für das fehlende Zertifikat-Pinning gibt es zumindest einen Teilschritt: Seit 2.0-rc0 ist laut Änderungsprotokoll „certificate transparency for known domains" aktiv. Das ist nicht dasselbe wie Pinning, aber es ist mehr als nichts.

Unverändert bleibt das, was am Modell selbst hängt: F-Droid baut die meisten Apps weiterhin selbst und signiert sie mit eigenen Schlüsseln, ihr vertraut also nach wie vor dem Entwickler und F-Droid. Ein Zwischenfazit, das wir vor einem Jahr nicht erwartet hätten: Der Client hat bei den Punkten aufgeholt, die sich mit Arbeit beheben liessen. Bei denen, die eine Grundsatzfrage sind, steht alles wie gehabt.

Der 30. September: was Google wirklich scharf geschaltet hat

Sechs Tage nach der Ankündigung kam der Stichtag. Laut Googles Übersicht zur Entwickler-Verifizierung gelten seit dem 30. September 2026 die neuen Schutzmechanismen für Nutzer, die Apps aus teilnehmenden Stores installieren — in Brasilien, Indonesien, Singapur und Thailand, auf zertifizierten Geräten ab Android 7. Teilnehmend sind laut den Leitfäden sieben Stores: 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 GetApps von Xiaomi.

F-Droid steht nicht auf dieser Liste, und direkt installierte APK-Dateien auch nicht. Googles FAQ sagt dazu wörtlich: „If you distribute your app through other stores, or if users sideload your app directly, these new verification requirements won't apply to your app yet." Das entscheidende Wort ist wie schon im August „yet". Die weltweite Ausdehnung auf alle Apps zertifizierter Geräte kündigt Google für 2027 an.

Neu ist dagegen, dass Google den sogenannten Advanced Flow inzwischen nachvollziehbar beschreibt. Im August hatten wir an dieser Stelle noch geschrieben, die Schritte liessen sich in Googles Dokumentation nicht nachprüfen. Das ist überholt. Die FAQ nennt sie jetzt einzeln: Entwicklermodus in den Systemeinstellungen einschalten, eine kurze Abfrage bestätigen, dass euch niemand dabei anleitet, das Telefon neu starten und neu anmelden, dann eine einmalige Wartezeit von einem Tag. Danach bestätigt ihr per Fingerabdruck, Gesicht oder PIN und könnt die Installation von Apps nicht verifizierter Entwickler für sieben Tage oder dauerhaft erlauben. Eine Warnung erscheint trotzdem bei jeder solchen App, mit der Schaltfläche „Install Anyway". Die Installation über ADB ist von der Wartezeit ausgenommen und bleibt laut Google unverändert.

Google begründet die 24 Stunden mit Betrugsmaschen, bei denen Opfer am Telefon zu sofortigen Änderungen gedrängt werden. Das Argument ist nicht aus der Luft gegriffen. Es ändert aber nichts daran, dass dieselbe Hürde künftig vor jedem steht, der freiwillig und mit Absicht einen anderen Bezugsweg wählt — und dass die Firma, die sie aufstellt, zugleich den grössten App-Store betreibt.

Worauf ihr beim Umstieg auf F-Droid 2.0 achten solltet

Ihr nutzt eine Panik-App mit F-Droid. Wenn ihr euch darauf verlasst, dass F-Droid auf ein Signal von Ripple oder einer ähnlichen App hin Apps löscht: Wartet mit dem Update, wie es das Projekt selbst empfiehlt. Sonst bemerkt ihr das Fehlen erst, wenn ihr die Funktion braucht.

Ihr habt die Privileged Extension installiert. Sie bleibt auf dem Gerät, wird aber von 2.0 ignoriert. Prüft nach dem Update, ob die Aktualisierungen bei euch wie erwartet durchlaufen; die Vorabfreigabe vor dem Herunterladen setzt Android 14 voraus.

Ihr ladet über Tor. Die Einstellung wandert in die Proxy-Einstellungen. Seht nach dem Update nach, ob sie dort korrekt übernommen wurde, bevor ihr die nächste App herunterladet.

Ihr habt noch ein Gerät mit Android 6. Für dieses Gerät gibt es kein 2.0. Bleibt bei 1.23.2.

Ihr wohnt nicht in Brasilien, Indonesien, Singapur oder Thailand. Für euch hat sich am 30. September nichts geändert. Das ist kein Grund zur Entwarnung, sondern ein gutes Jahr Vorlauf. Wer bisher auf eine Handvoll Apps aus freien Quellen angewiesen ist, nutzt die Zeit, um sich ein lokales Archiv der installierten APK-Dateien anzulegen.

Fazit: F-Droid 2.0 rüstet auf, bevor Google den Schalter umlegt

F-Droid 2.0 ist mehr als ein neuer Anstrich. Der Client installiert endlich so, wie ein moderner Store unter Android installieren soll, er zielt auf eine aktuelle Android-Version und verzichtet auf die Privileged Extension, die wir selbst als Schwachstelle beschrieben haben. Dafür verlieren ausgerechnet die Nutzer mit dem höchsten Schutzbedarf vorerst eine Funktion, und das Projekt sagt ihnen das ehrlich, statt es zu verstecken.

An der grösseren Lage ändert das alles nichts. Der 30. September hat F-Droid noch nicht getroffen, weil Google den Hebel zuerst bei sieben Stores angesetzt hat. 2027 trifft er alle, und dann hilft der schönste Client nichts, wenn die Entwickler darin vor der Wahl stehen, ihren Ausweis bei Google zu hinterlegen oder ihren Nutzern einen Tag Wartezeit zuzumuten. F-Droid hat die eigene Hausaufgabe gemacht. Die von Google ist noch offen, und sie wird nicht in Kotlin geschrieben, sondern in Brüssel, Bern und Mountain View entschieden.

Quellen und weiterführende Links

• F-Droid: F-Droid 2.0: A New Chapter for Android Freedom, 24. September 2026 — Neuerungen, entfallene Funktionen, Verteilung „over the coming weeks"
• F-Droid: Paketseite des klassischen Clients — 1.23.2 empfohlen, 2.0.0 und 2.0.1 als Beta
• F-Droid: Paketseite von F-Droid Basic — 2.0.1 empfohlen, Android 7.0 oder neuer
• F-Droid Client: Änderungsprotokoll — target SDK 37 ab 2.0-alpha10, Certificate Transparency ab 2.0-rc0
• F-Droid: Running on old Android versions — passende Client-Versionen für ältere Geräte
• Android Developers: Android 14 features and APIs — Vorabfreigabe mit requestUserPreapproval()
• Android Developers: Developer verification — Zeitplan, Stichtag 30. September 2026, Ausdehnung 2027
• Android Developers: Developer verification guides — die sieben teilnehmenden Stores
• Android Developers: Developer verification FAQ — Geltungsbereich des Stichtags, Ablauf des Advanced Flow, ADB

The post F-Droid 2.0: was neu ist und was wegfällt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wer hier regelmässig mitliest, kennt die Richtung: Beim Start der KI-Videoüberwachung in Berlin ging es darum, wie Kameras im öffentlichen Raum zu Sensoren werden. Netzpolitik.org hat am 29. September unter dem Titel „Diese Geheimdienstreform betrifft uns alle" aufgezählt, wen das Vorhaben trifft: Ärzte, Journalisten, Autowerkstätten, Betreiber von Kameras, Internetnutzer. Der Aufzählung ist nichts hinzuzufügen. Wohl aber eine Frage, die in der Liste untergeht: Was wird aus einem Nachrichtendienst, wenn er handeln darf?

Geheimdienstreform: was der Regierungsentwurf ändert

Der Gesetzentwurf trägt den Titel „Entwurf eines Gesetzes zur Reform des Nachrichtendienstrechts", Drucksache 21/7868 vom 7. September 2026, eingebracht von der Bundesregierung. Unter „Alternativen" steht dort ein einziges Wort: „Keine." Kanzleramtsministerin Nina Warken (CDU) nannte das Vorhaben in der ersten Lesung laut Textarchiv des Bundestags „die grösste Novellierung des Nachrichtendienstrechts in der Geschichte des Landes". Wer einen Rekord ankündigt, sollte damit rechnen, dass jemand nachmisst.

Neu geschrieben werden das Bundesverfassungsschutzgesetz und das BND-Gesetz, dazu kommt ein eigenes Gesetz für den Unabhängigen Kontrollrat. Laut Bundestag sieht der Entwurf unter anderem vor:

• dass der BND „erhobene Daten ohne vorherige Sichtung für einen Zeitraum von sechs Monaten (Inhaltsdaten) beziehungsweise bis zwölf Monaten (Metadaten) speichern darf",
• dass Bundesamt für Verfassungsschutz (BfV) und BND „tatbestandlich eng begrenzte Interventionsbefugnisse bei bestimmten Gefahrensituationen" erhalten,
• neue Befugnisse zur Auswertung technischer Spuren in der Infrastruktur von Cyberangriffen,
• dass der Unabhängige Kontrollrat sowohl die Vorabkontrolle von Anordnungen als auch die Datenschutzkontrolle übernimmt.

Dazu kommen Pflichten für Dritte, die im Entwurf selbst stehen: Videoanlagen sollen dem Verfassungsschutz auf Ersuchen zur Verfügung stehen, Autohersteller und Werkstätten sollen Telemetriedaten liefern. Dazu gleich mehr. Federführend ist der Innenausschuss.

Innenminister Alexander Dobrindt (CSU) fasste den Zweck in der Debatte in einen Satz, der mehr verrät, als ihm vermutlich lieb ist: „Aus Informationsbeschaffung über Bedrohungen wird echte Abwehr von Gefahren." So zitiert ihn das Textarchiv des Bundestags. Genau dieser Satz ist das Problem.

Das Trennungsgebot: warum Beobachten und Eingreifen getrennt sind

In Deutschland gilt seit der Nachkriegszeit das sogenannte Trennungsgebot: Nachrichtendienste sammeln Informationen, die Polizei greift ein. Netzpolitik.org erinnert in seinem Bericht zur ersten Lesung daran, woher es kommt: aus der Erfahrung mit einer Geheimpolizei, die beides in einer Hand hatte. Das ist keine historische Fussnote, sondern eine Konstruktionsregel. Wer im Verborgenen ermittelt, soll nicht zugleich durchgreifen dürfen.

Diese Trennung hat einen Preis, und den zahlt der Bürger bereits heute. Nachrichtendienste dürfen früher und breiter Daten erheben als die Polizei. Sie brauchen keine konkrete Gefahr, ihnen genügen „tatsächliche Anhaltspunkte" für eine Bedrohung. Das Bundesverfassungsgericht hat diese niedrigere Schwelle nicht einfach hingenommen, sondern begründet. Die Gesellschaft für Freiheitsrechte (GFF) zitiert in ihrer Stellungnahme zum Referentenentwurf das Urteil zum Bayerischen Verfassungsschutzgesetz vom 26. April 2022 (1 BvR 1619/17, Randnummer 156) im Wortlaut:

„Dass eine Verfassungsschutzbehörde nicht über eigene operative Anschlussbefugnisse verfügt, rechtfertigt es im Grundsatz, die ihr zur Wahrnehmung ihrer Beobachtungsaufgaben eingeräumten Datenerhebungsbefugnisse im Vergleich zu den Befugnissen einer Polizeibehörde wegen des geringeren Eingriffsgewichts an modifizierte Eingriffsschwellen zu knüpfen."

Lest den Satz zweimal. Die niedrige Schwelle ist erlaubt, weil der Dienst nicht handeln darf. Sie ist der Ausgleich für die fehlende Hand, nicht ein Vorrecht an sich. Wer die Hand nachliefert, entzieht der Schwelle ihre Begründung.

Aus Beobachten wird Eingreifen

Und genau das tut der Entwurf. „Interventionsbefugnisse bei bestimmten Gefahrensituationen" ist Verwaltungsdeutsch für: Der Dienst darf selbst etwas unternehmen. Dobrindt spricht von „echter Abwehr von Gefahren". Gefahrenabwehr ist im deutschen Recht der Inbegriff von Polizeiarbeit. Wer sie einem Nachrichtendienst überträgt, baut keinen moderneren Nachrichtendienst, sondern eine zweite Polizei — eine, die im Verborgenen arbeitet und deren Erhebungsschwellen niedriger liegen.

Die GFF nennt das in ihrer Stellungnahme eine „Verpolizeilichung" und schreibt: „Die strenge Trennung zwischen den nur überwachenden, aber nicht operierenden Nachrichtendiensten und der dann eingreifenden Polizei wird eingerissen." Die Linken-Abgeordnete Clara Bünger sprach im Plenum von einer „neuen deutschen Geheimpolizei". Das ist Opposition, und Opposition übertreibt von Berufs wegen. Hier muss sie allerdings nicht viel übertreiben, denn der Innenminister liefert die Vorlage selbst.

Konstantin von Notz von den Grünen, der eine Stärkung des BND ausdrücklich mitträgt, forderte laut Bundestag, Dobrindts „überzogene Pläne für die Geheimdiensttätigkeit im Inland" zurückzufahren. Dass ausgerechnet der Befürworter eines stärkeren Auslandsdienstes vor dem Inlandsteil warnt, ist der aufschlussreichste Satz der ganzen Debatte.

Wie eng die neuen Eingriffsbefugnisse in der Praxis tatsächlich gefasst sind, lässt sich an dieser Stelle nicht abschliessend sagen. Die Paragrafen dazu stehen im hinteren Teil des Entwurfs, und das Adjektiv „eng" steht in jedem Gesetz am Anfang. Entscheidend ist ein anderer Punkt: Selbst eine eng gefasste Eingriffsbefugnis verändert, was die Erhebungsbefugnisse davor rechtfertigt. Ein Dienst, der eingreifen kann, sammelt nicht mehr nur Lagebilder. Er sammelt für den eigenen Zugriff.

Dazu passt, was der Referentenentwurf vom Juli in § 37 des neuen Verfassungsschutzgesetzes vorsah: eine automatisierte Datenanalyse über die gespeicherten Bestände, die die GFF als „schwerwiegenden Grundrechtseingriff" bewertet. Wer die Debatte um Palantir bei deutschen Polizeibehörden verfolgt hat, weiss, wie schnell aus Analyse ein Werkzeug für Zugriffe wird. Ein Dienst mit Eingriffsbefugnissen und einer Analysemaschine ist nicht mehr der stille Beobachter, für den die alten Regeln geschrieben wurden.

Jede Kamera ein Fenster: § 15 des neuen Verfassungsschutzgesetzes

Am deutlichsten wird die Verschiebung an einer Vorschrift, die auf den ersten Blick technisch klingt. § 15 des neuen Bundesverfassungsschutzgesetzes heisst „Verpflichtende Ersuchen an Verfügungsberechtigte von Einrichtungen zur Videoüberwachung". Der Wortlaut in Absatz 1: „Verfügungsberechtigte privater und öffentlicher Einrichtungen zur Videoüberwachung des öffentlich zugänglichen Raums haben auf Ersuchen des Bundesamtes für Verfassungsschutz 1. die Mitbenutzung der Einrichtung durch das Bundesamt für Verfassungsschutz zu ermöglichen". Dazu kommt die Übermittlung der Bilder in Echtzeit. Zulässig ist das nach Absatz 2 „nur im Fall wenigstens erheblich beobachtungsbedürftiger Bedrohungen".

Übersetzt: Die Kamera über dem Eingang des Supermarkts, die am Bahnhofsvorplatz, die des Parkhauses — sie alle können auf Anfrage zum Auge des Verfassungsschutzes werden. Nicht wegen eines konkreten Verdachts gegen eine bestimmte Person, sondern bei einer „erheblich beobachtungsbedürftigen Bedrohung", also einer nachrichtendienstlichen Schwelle.

Die GFF hält das für verfassungswidrig. Das Eingriffsgewicht der Massnahme, die im Entwurf nicht einmal als nachrichtendienstliches Mittel kategorisiert sei, nennt sie „enorm" und schreibt: „Dies ist auch unter Berücksichtigung der vorgesehenen Eingriffsschwelle der erheblich beobachtungsbedürftigen Bedrohung unverhältnismässig." Netzpolitik.org fasst die Reichweite in einem Satz: „Faktisch alle Menschen, die sich in Deutschland aufhalten, werden von solchen Videoüberwachungen erfasst."

Für diesen Blog ist das kein abstraktes Thema. Im Kaufratgeber zu Überwachungskameras ohne Cloud ging es darum, dass eine Kamera nur so viel preisgibt, wie ihre Architektur zulässt. Mit § 15 kommt eine Ebene dazu, die keine Architektur abfängt: Nicht der Hersteller will mitschauen, sondern der Staat, und er fragt den Betreiber. Der Betreiber muss Ja sagen. Und in Berlin wird gerade vorgeführt, wie aus Bildern Verhaltensdaten werden. Wer beides zusammendenkt, ahnt, wohin die Reise geht — und die Tickets sind schon gelöst.

Das Auto als Informant: § 11 und die Telemetrie

§ 11 verpflichtet eine Reihe von Unternehmen zur Auskunft, wenn der Verfassungsschutz nach § 9 ersucht — also wenn das „auf Grund tatsächlicher Anhaltspunkte im Einzelfall zur Aufklärung von Bedrohungen erforderlich ist". Genannt werden Anbieter von Güter- und Personenverkehr, digitale Dienste, technische Zahlungsdienste, die nach dem Geldwäschegesetz Verpflichteten — und in Nummer 2 „Kraftfahrzeughersteller oder Kraftfahrzeugwerkstätten zu Telemetriedaten". Werkstätten sollen nach Absatz 4 nur dann gefragt werden, wenn die Anfrage beim Hersteller nicht möglich ist oder den Zweck gefährden würde.

Ein modernes Auto weiss, wo es war, wann, wie schnell, und oft auch, wer am Steuer sass. Diese Daten liegen beim Hersteller, weil der Hersteller sie haben wollte. Jetzt will sie auch der Verfassungsschutz. Laut netzpolitik.org warnt der Zentralverband Deutsches Kraftfahrzeuggewerbe, dass „Autohäuser und Kfz-Werkstätten zum verlängerten Arm der Nachrichtendienste werden", und der Verband der Automobilindustrie hält fest: „ein etwaiger direkter Zugriff in das Auto ist aus Sicherheitsgründen abzulehnen". Wenn die Autoindustrie beim Datenschutz bremst, ist das ungefähr so, als würde der Fuchs um bessere Zäune für den Hühnerstall bitten. Recht hat sie trotzdem.

Der Punkt ist derselbe wie bei den Kameras: Private Infrastruktur, die für ganz andere Zwecke gebaut wurde, wird zur Quelle des Nachrichtendienstes. Jede Datensammlung, die ein Unternehmen aus Bequemlichkeit oder Geschäftsinteresse anlegt, wird so zur Vorratskammer für Behörden. Das ist der Grund, warum Datensparsamkeit keine Marotte ist, sondern Sicherheitsarchitektur. Wie viel schon die Umstände einer Kommunikation verraten, ohne dass jemand den Inhalt kennt, steht im Beitrag zu Metadaten bei Messengern; Bewegungsdaten eines Autos sind dieselbe Sorte Information auf vier Rädern.

BND-Gesetz: sechs Monate auf Vorrat, ungesichtet

Beim Auslandsnachrichtendienst geht es um eine andere Grössenordnung. Der BND soll laut Bundestag Inhaltsdaten sechs Monate und Metadaten bis zu zwölf Monate speichern dürfen, ohne sie vorher zu sichten. Erst sammeln, dann schauen, was drin ist — das ist die Logik der Vorratsdatenspeicherung, verlegt in einen Dienst, dessen Arbeit niemand von aussen sieht.

Dazu kommt die Frage, wie viel er überhaupt abgreifen darf. Der frühere Ministerialdirektor Peter Schantz schreibt in seiner Stellungnahme für die GFF zum Referentenentwurf, die neue Volumengrenze von 15 Prozent beziehe sich auf alle Telekommunikationsnetze und nicht auf einzelne Leitungen. Sein Befund: „Selbst am grössten deutschen Internetknotenpunkt werden in der Regel nicht mehr als 15 Prozent der Kapazitäten genutzt." Eine Grenze, die über der tatsächlichen Auslastung liegt, begrenzt nichts. Sie sieht nur aus wie eine.

Wer den Beitrag zu FISA Section 702 gelesen hat, erkennt das Muster wieder: Die Erfassung am Backbone unter dem Etikett der Auslandsaufklärung, und die Inländer, die dabei „nebenbei" im Netz hängen bleiben. Die Empörung über amerikanische Praktiken war in Berlin immer gross. Beim Nachbauen ist sie es offenbar weniger.

Schantz kritisiert ausserdem die Weitergabe „ungefilterter Kommunikation" an die Bundeswehr und ausländische Dienste und die Regeln zu aktiven Cybermassnahmen, bei denen er „ein autonomes Handeln der automatisierten Systeme" für möglich hält. Seine Stellungnahme bezieht sich auf den Referentenentwurf vom Juli; welche dieser Punkte im Regierungsentwurf unverändert stehen, lässt sich ohne Lektüre des vollständigen BND-Teils nicht für jeden einzeln bestätigen. Die Speicherfristen und die Interventionsbefugnisse bestätigt der Bundestag selbst.

Ärzte zweiter Klasse

Einen Bereich gibt es, in dem die Reform nicht mehr erlaubt, sondern weniger schützt: die Berufsgeheimnisträger. Nach dem Referentenentwurf, so die Bundesärztekammer in ihrer Stellungnahme vom 27. Juli 2026, sollen Geistliche, Verteidiger und Abgeordnete nach § 32 Absatz 1 des neuen Verfassungsschutzgesetzes absolut geschützt sein. Ärzte stehen nur unter relativem Schutz nach Absatz 2. Relativ heisst: Im Einzelfall wägt die Behörde ab, ob ihr Aufklärungsinteresse schwerer wiegt als das Vertrauensverhältnis.

Die Bundesärztekammer fordert: „Die Arzt-Patienten-Beziehung muss absolut vor Massnahmen der Nachrichtendienste geschützt werden." Netzpolitik.org berichtet am 29. September, dass es auch im Regierungsentwurf bei der Abwägung bleibt, und zitiert aus der Ärzteschaft: „Wenn intimste Informationen betroffen sein können, darf das nicht einer Abwägungsentscheidung einer Behörde überlassen sein." Bei Journalisten sieht es nicht besser aus. Auch ihr Schutz ist relativ, und gerade ihre internationalen Kontakte machen sie für einen Auslandsdienst interessant.

Wer die Abwägung allein der Behörde überlässt, die etwas wissen will, hat die Abwägung bereits entschieden. Es mag Behörden geben, die gegen ihr eigenes Interesse entscheiden. Auf diese Seltenheit sollte kein Grundrecht gebaut sein.

Die Gegenposition: Bedrohung, Kontrolle, Karlsruhe

Es wäre billig, das Vorhaben nur als Machtgier abzutun. Die Befürworter haben Argumente, und drei davon verdienen eine Antwort.

Die Bedrohungslage ist real

Sabotage an Infrastruktur, Cyberangriffe staatlicher Akteure, Terror — der Entwurf begründet sich mit einer verschärften Bedrohungslage, und die ist nicht erfunden. Aus der SPD-Fraktion hiess es in der Debatte laut Bundestag, es gehe darum, „Gefahren abzuwehren und die Bevölkerung zu schützen". Nur: Für Gefahrenabwehr gibt es eine Behörde, die dafür gebaut ist, mit Schwellen, Richtervorbehalten und Rechtsschutz, die dafür gebaut sind. Wenn der Verfassungsschutz eine Gefahr erkennt, kann er sie übermitteln. Dass die Übermittlung an Voraussetzungen hängt, ist kein Fehler im System, sondern das System. Die Bedrohung rechtfertigt bessere Werkzeuge. Sie rechtfertigt nicht, die Werkzeuge in die Hand zu legen, die dafür die niedrigsten Hürden hat.

Der Kontrollrat wird gestärkt

Richtig ist: Der Unabhängige Kontrollrat soll künftig Vorabkontrollen und Datenschutzkontrolle bündeln. Das ist ein Fortschritt gegenüber dem bisherigen Flickenteppich. Aber Kontrolle prüft, ob eine Massnahme die gesetzlichen Voraussetzungen erfüllt. Sie kann keine Voraussetzung anheben, die das Gesetz zu niedrig ansetzt. Schantz bemängelt zudem, dass dem Kontrollrat nach dem Wegfall der Zuständigkeit der Bundesdatenschutzbeauftragten die technische Expertise fehle. Ein Kontrolleur, der den Maschinenraum nicht lesen kann, kontrolliert die Formulare.

Karlsruhe verlangt eine Reform

Ebenfalls richtig: Das Bundesverfassungsgericht hat am 8. Oktober 2024 Teile der strategischen Inland-Ausland-Fernmeldeüberwachung des BND beanstandet. Laut Legal Tribune Online hat der Bundestag „Zeit bis zum 31. Dezember 2026, um die Mängel zu beheben". Die Frist ist ein Grund, das Gesetz zu reformieren. Sie ist kein Grund, dabei Interventionsbefugnisse für den Inlandsdienst, den Zugriff auf private Kameras und Telemetriedaten von Autos gleich mit durchzuwinken. Karlsruhe hat Mängel beim Schutz der Grundrechte festgestellt, nicht einen Mangel an Befugnissen.

Der Blick über die Grenze: die Schweiz und ihr eigenes NDG

Für Leser in der Schweiz liegt der Gedanke nahe, das sei ein deutsches Problem. Das stimmt nur halb. Wer in Deutschland unterwegs ist, an Kameras vorbeigeht oder ein Auto fährt, das Telemetrie an einen deutschen Hersteller funkt, ist von § 11 und § 15 genauso betroffen wie ein Einheimischer. Und auch in Bern wird gerade am Nachrichtendienstrecht gebaut.

Der Bundesrat hat die Botschaft zum Grundpaket der NDG-Revision am 28. Januar 2026 verabschiedet. Auch sie erweitert Befugnisse: Der Nachrichtendienst des Bundes soll bei schweren Bedrohungen Daten bei Finanzintermediären erheben können, und Massnahmen, die bisher dem Terrorismus vorbehalten waren, sollen auch gegen gewalttätigen Extremismus möglich werden. Die Digitale Gesellschaft und ihre Partner fordern in einer gemeinsamen Mitteilung vom 2. Juni 2026, die Vorlage zurückzuweisen, und erinnern daran, dass das Bundesverwaltungsgericht die Kabelaufklärung im November 2025 für nicht grundrechtskonform erklärt hat. Das bestätigt auch das VBS selbst: Das Urteil A-6444/2020 vom 19. November 2025 hält fest, dass die gesetzlichen Grundlagen der Funk- und Kabelaufklärung „in bestimmten Bereichen nicht grundrechtskonform sind". Die Schweiz ist also kein Gegenmodell.

Aber an zwei Stellen hat sie anders entschieden, und genau an den Stellen, um die es hier geht. Erstens hat der Bundesrat laut seiner Mitteilung darauf verzichtet, die Überwachung von Berufsgeheimnisträgern wie Anwälten und Ärzten als Drittpersonen zu ermöglichen — wegen der Rückmeldungen aus der Vernehmlassung. Zweitens hat der Ständerat am 16. September 2026 die Vorlage zwar mit 41 zu 1 Stimmen bei 2 Enthaltungen angenommen, aber laut der Nachrichtenagentur SDA, wie Radio Central meldet, mit 24 zu 15 Stimmen die Befugnis gestrichen, Informationen über die politische Tätigkeit von Personen und Organisationen zu bearbeiten. Laut VBS hat er ausserdem mit einem Einzelantrag von Beat Rieder bewusst eine Differenz zum Nationalrat geschaffen, damit Zeit bleibt, die Wahrung von Berufsgeheimnissen klar zu regeln.

Das ist kein Grund zum Feiern. Aber es zeigt, dass ein Parlament die Frage nach den Berufsgeheimnissen stellen kann, bevor das Gesetz verabschiedet ist, und nicht erst danach vor Gericht.

Wie es weitergeht

Das Verfahren in Berlin hat einen engen Takt, und die nächsten Termine stehen fest.

• 7. Oktober 2026: Der Innenausschuss berät in seiner 45. Sitzung über den Entwurf und laut Tagesordnung über die „Durchführung einer öffentlichen Anhörung am Montag, dem 12. Oktober 2026".
• 12. Oktober 2026: Öffentliche Anhörung der Sachverständigen im Innenausschuss. Erfahrungsgemäss werden dort die Stellungnahmen von GFF, Bundesärztekammer und Medienverbänden noch einmal vorgetragen; spannend wird, ob die Koalition danach am Arztgeheimnis, an § 15 oder an den Interventionsbefugnissen etwas ändert.
• 31. Dezember 2026: Ablauf der Frist aus dem Beschluss des Bundesverfassungsgerichts vom 8. Oktober 2024. Bis dahin muss zumindest der beanstandete Teil der BND-Überwachung neu geregelt sein. Die Frist erzeugt Zeitdruck, und Zeitdruck ist erfahrungsgemäss der beste Freund grosser Befugnisse.
• Nach der Verabschiedung: Von Notz rechnet laut netzpolitik.org damit, dass das Gesetz in Karlsruhe landet. Die GFF hält den Entwurf in ihrer Stellungnahme für „in weiten Teilen verfassungswidrig".

In der Schweiz geht die NDG-Revision nach der Ständeratsdebatte vom 16. September 2026 zurück in den Nationalrat. Offen sind dort unter anderem die Bearbeitung politischer Tätigkeiten und die Regelung der Berufsgeheimnisse.

Fazit: Wer Gefahren abwehrt, braucht Polizeischwellen

Die Geheimdienstreform ist kein Sammelsurium einzelner Zumutungen, auch wenn sie sich so liest. Sie folgt einem Plan, und Dobrindt hat ihn ausgesprochen: Aus Informationsbeschaffung soll Gefahrenabwehr werden. Das Bundesverfassungsgericht hat Nachrichtendiensten niedrigere Schwellen zugestanden, weil sie nicht eingreifen dürfen. Der Entwurf behält die niedrigen Schwellen und gibt die Eingriffe dazu. Damit fällt die Begründung weg, auf der das ganze Gefüge ruht.

Was danach übrig bleibt, ist eine Behörde, die mit nachrichtendienstlichen Hürden sammelt und mit polizeilicher Wirkung handelt, die auf private Kameras und Autodaten zugreift und bei der das Arztgeheimnis zur Verhandlungsmasse wird. Die Bundesregierung nennt das Modernisierung. Die Generation, die das Trennungsgebot erfunden hat, hätte dafür ein anderes Wort gehabt, und es stand nicht in einer Pressemitteilung.

Will der Gesetzgeber Gefahren abwehren, soll er es der Polizei erlauben, mit Polizeischwellen und Richtervorbehalt. Will er Nachrichtendienste, die mehr sehen, soll er sie sehen lassen und das Handeln bei denen belassen, die dafür kontrolliert werden. Beides in eine Hand zu legen, ist keine Modernisierung. Es ist der Rückbau einer Lehre, die Deutschland teuer bezahlt hat.

Quellen und weiterführende Links

1. Bundestag: Drucksache 21/7868, Entwurf eines Gesetzes zur Reform des Nachrichtendienstrechts, 07.09.2026 — dserver.bundestag.de
2. Bundestag, Textarchiv: Gesetzentwurf zur Reform des Nachrichtendienstrechts beraten, 24.09.2026 — bundestag.de
3. Bundestag, Innenausschuss: Mitteilung zur 45. Sitzung am 07.10.2026 — bundestag.de
4. Gesellschaft für Freiheitsrechte: Stellungnahme zum Referentenentwurf (Verfassungsschutz), 14.07.2026 — freiheitsrechte.org
5. Peter Schantz für die GFF: Stellungnahme zur Reform des BND-Gesetzes, 14.07.2026 — freiheitsrechte.org
6. Bundesärztekammer: Stellungnahme zum Nachrichtendienstrecht, 27.07.2026 — bundesaerztekammer.de
7. netzpolitik.org: Ärzte, Aktivistinnen und Internetnutzer: Diese Geheimdienstreform betrifft uns alle, 29.09.2026 — netzpolitik.org
8. netzpolitik.org: Bundestagsdebatte zur Geheimdienstreform: Zwischen Schreddern und Nachbessern, 24.09.2026 — netzpolitik.org
9. Legal Tribune Online: BVerfG zur strategischen BND-Überwachung (1 BvR 1743/16) — lto.de
10. Schweizerischer Bundesrat: Revision des Nachrichtendienstgesetzes, Botschaft vom 28.01.2026 — admin.ch
11. VBS: Nachrichtendienstgesetz, Grundpaket im Parlament — vbs.admin.ch
12. VBS: Urteil des Bundesverwaltungsgerichts zur Funk- und Kabelaufklärung — vbs.admin.ch
13. Digitale Gesellschaft: Revision Nachrichtendienstgesetz: Rückweisen statt Massenüberwachung ausbauen, 02.06.2026 — digitale-gesellschaft.ch
14. Radio Central (SDA): Ständerat genehmigt revidiertes Nachrichtendienstgesetz deutlich, 16.09.2026 — radiocentral.ch

The post Geheimdienstreform: Polizeibefugnisse ohne Polizeischwelle appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Zeitpunkt ist nicht zufällig. Am 15. Oktober 2026 erscheint Forgejo 17, zwei Wochen später endet der Support für Forgejo 16. Wer jetzt einsteigt, sollte deshalb wissen, welche Version er in die Compose-Datei schreibt, bevor er sie schreibt. Die Grundlagen zu Docker stehen in Docker Basics und Installation, sie werden hier nicht wiederholt.

Forgejo selbst hosten: was ihr bekommt

Forgejo ist eine sogenannte Forge: eine Weboberfläche rund um Git, die aus nackten Repositories eine Arbeitsumgebung macht. Dazu gehören Issues, Pull Requests, ein Wiki, Releases, Organisationen mit Teams und ein Paketregister. Git selbst bleibt dabei unverändert; Forgejo verwaltet nur, wer worauf zugreifen darf und was drumherum passiert.

Die Software hat eine Vorgeschichte, die ihren Charakter erklärt. Forgejo entstand im Oktober 2022 als Abspaltung von Gitea, nachdem ein kommerzielles Unternehmen die Domains und die Marke von Gitea übernommen hatte, ohne die Gemeinschaft zu fragen. Anfang 2024 wurde daraus ein Hard Fork, seither entwickeln sich beide Codebasen auseinander. Getragen wird Forgejo vom gemeinnützigen Verein Codeberg e.V. Mit Version 9.0 hat das Projekt ausserdem die Lizenz von MIT auf GPLv3+ umgestellt, mit der Begründung: "Copyleft licenses do not only benefit the developers. They also guarantee freedoms to users of the software."

Warum überhaupt weg von GitHub? GitHub gehört seit dem Kauf im Juni 2018 für 7,5 Milliarden Dollar Microsoft und unterliegt damit dem US-Recht, das wir in Der CLOUD Act: Eure Daten und die amerikanische Software ausführlich beschrieben haben. Für ein öffentliches Open-Source-Projekt mag das verschmerzbar sein. Für private Repositories mit Konfigurationen, Notizen und halbfertigen Ideen ist es eine andere Frage.

Was diese Anleitung bewusst nicht abdeckt, ist Forgejo Actions, das eingebaute CI-System. Es führt Workflows nicht selbst aus, sondern übergibt sie an separate Runner, und ist an GitHub Actions angelehnt, ohne auf Kompatibilität ausgelegt zu sein. Das ist ein eigenes Thema mit eigenen Sicherheitsfragen.

Welche Version: Forgejo LTS oder die stabile Reihe

Forgejo veröffentlicht alle drei Monate eine neue Hauptversion, und die jeweils erste des Jahres ist eine LTS-Version mit längerem Support. Der offizielle Release-Zeitplan nennt für die nächsten Monate folgende Daten:

• Forgejo 15.0 (LTS): erschienen am 16. April 2026, Support bis 15. Juli 2027
• Forgejo 16.0: erschienen am 16. Juli 2026, Support bis 29. Oktober 2026
• Forgejo 17.0: geplant für den 15. Oktober 2026, Support bis 28. Januar 2027
• Forgejo 19.0 (LTS): geplant für den 15. April 2027

Stand heute sind laut der Release-Übersicht Forgejo 16.0.5 und die LTS-Fassung 15.0.9 aktuell, beide vom 17. September 2026.

Für einen Server, den ihr nebenher betreibt, ist die LTS-Reihe die vernünftige Wahl. Die Docker-Installationsseite von Forgejo hält fest, dass der Sprung von einer Hauptversion zur nächsten, etwa von 12 auf 13, "a manual operation and human verification" verlangt. Mit der stabilen Reihe steht diese Handarbeit viermal im Jahr an, mit der LTS-Reihe einmal. Wer neue Funktionen sofort haben will, nimmt die stabile Reihe und plant die Quartalsupdates fest ein; alle anderen schreiben den Tag 15 in die Compose-Datei und bekommen Fehlerbehebungen und Sicherheitskorrekturen automatisch.

Ein Punkt spricht zusätzlich für Gelassenheit: Forgejo 16 ist ausdrücklich "a non-LTS release". Wer jetzt auf 16 einsteigt, muss in vier Wochen ohnehin auf 17 wechseln.

Voraussetzungen für den eigenen Git-Server

Ihr braucht einen Linux-Server mit Docker und dem Compose-Plugin aus dem offiziellen Docker-Repository. Achtung: Die Installationsanleitung in unserem Docker-Grundlagenartikel installiert das Compose-Plugin nicht mit. Holt es laut Docker-Dokumentation nach und prüft die Version:

sudo apt-get update
sudo apt-get install docker-compose-plugin
docker compose version

Dazu kommen eine Domain oder Subdomain, die auf euren Server zeigt, in dieser Anleitung git.example.ch, sowie ein laufendes Caddy. Feste Hardwareanforderungen nennt die offizielle Forgejo-Dokumentation nicht.

An Ports werden gebraucht: 80 und 443 für Caddy, wie gehabt, und 222 für Git über SSH. Port 22 bleibt für den SSH-Zugang zum Server selbst reserviert. Wer den Server über das Internet erreichbar macht, gibt Port 222 in der Firewall frei; wer Forgejo nur im Heimnetz oder über Wireguard nutzt, lässt ihn zu.

Kurz vor dem Loslegen noch ein Wort zur eigenen Motivation: Einen eigenen Git-Server aufzusetzen, um ein Dotfiles-Repository mit drei Commits zu hosten, ist klassische Selfhosting-Überdimensionierung. Wir machen es trotzdem, aus Prinzip.

Die Compose-Datei: Forgejo mit SQLite

Die Forgejo-Dokumentation empfiehlt in ihren Konfigurationsempfehlungen für Instanzen mit geringer bis mittlerer Last ausdrücklich SQLite, weil sie einfach ist, keine Wartung braucht und als eine einzige Datei auf der Platte liegt. PostgreSQL oder MySQL empfiehlt sie erst für viel Betrieb. Für einen privaten Git-Server heisst das: Ein Container genügt.

Legt ein Verzeichnis an und prüft, welche Benutzer- und Gruppen-ID euer Konto hat:

sudo mkdir -p /opt/forgejo
sudo chown $USER: /opt/forgejo
cd /opt/forgejo
id -u
id -g

Die beiden Zahlen gehören gleich in die Compose-Datei. Auf den meisten Einzelplatzsystemen ist es 1000. Legt nun /opt/forgejo/compose.yml mit folgendem Inhalt an:

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:15
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__server__DOMAIN=git.example.ch
      - FORGEJO__server__ROOT_URL=https://git.example.ch/
      - FORGEJO__server__SSH_DOMAIN=git.example.ch
      - FORGEJO__server__SSH_PORT=222
      - FORGEJO__server__SSH_LISTEN_PORT=22
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "127.0.0.1:3000:3000"
      - "222:22"

Der Aufbau folgt dem Beispiel aus der Docker-Installationsseite von Forgejo, mit drei Änderungen: dem Tag 15 statt 16, den Servereinstellungen als Umgebungsvariablen und der Bindung von Port 3000 an 127.0.0.1.

Was die einzelnen Zeilen tun

USER_UID und USER_GID legen fest, unter welcher ID Forgejo im Container läuft. Die Dokumentation verlangt, dass das Datenverzeichnis genau diesem Benutzer gehört. Stimmt das nicht, startet der Container nicht sauber.

Die Variablen mit FORGEJO__ am Anfang sind Einträge in der Konfigurationsdatei app.ini, geschrieben nach dem Muster FORGEJO__abschnitt__SCHLÜSSEL. So bleibt die gesamte Konfiguration in einer Datei, die ihr versionieren und sichern könnt. Eine Einschränkung nennt die Dokumentation selbst: Einen bestehenden Wert könnt ihr über Umgebungsvariablen nicht löschen, nur überschreiben.

ROOT_URL ist die Adresse, unter der Forgejo von aussen erreichbar ist, und damit die Grundlage jedes Links, den Forgejo erzeugt. SSH_PORT ist laut Konfigurationsreferenz der Port, der in der Klon-Adresse erscheint. Ohne diese Zeile zeigt Forgejo Adressen mit Port 22 an, die bei euch ins Leere laufen. SSH_LISTEN_PORT gilt für den eingebauten SSH-Server; das Standard-Image benutzt stattdessen OpenSSH im Container auf Port 22. Die Zeile ist eine Absicherung dafür, dass niemand später die beiden Ports verwechselt.

Die Portzeile 127.0.0.1:3000:3000 sorgt dafür, dass die Weboberfläche nur auf dem Server selbst erreichbar ist. Von aussen führt der Weg ausschliesslich über Caddy. Die Zeile 222:22 leitet Port 222 des Servers auf den SSH-Dienst im Container weiter.

Wann ihr doch PostgreSQL nehmt

Plant ihr eine Instanz für einen Verein oder ein Team mit regem Betrieb, ergänzt ihr einen Datenbankdienst. Die Docker-Seite von Forgejo zeigt dafür diese Erweiterung, die in environment des Forgejo-Dienstes und als zweiter Dienst dazukommt:

      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=ein-langes-zufallspasswort

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=ein-langes-zufallspasswort
      - POSTGRES_DB=forgejo
    networks:
      - forgejo
    volumes:
      - ./postgres:/var/lib/postgresql/data

Beim Forgejo-Dienst kommt zusätzlich depends_on: [db] hinzu. Das Passwort muss an beiden Stellen identisch sein. Die Dokumentation verwendet in ihrem Beispiel forgejo als Passwort; übernehmt das nicht.

Erster Start und das Administratorkonto

Legt das Datenverzeichnis an, übergebt es der ID aus der Compose-Datei und startet den Container:

mkdir -p /opt/forgejo/forgejo
sudo chown -R 1000:1000 /opt/forgejo/forgejo
docker compose up -d
docker compose logs -f server

Wenn die Logs zur Ruhe kommen, beendet ihr sie mit Strg+C. Der Container läuft weiter.

Jetzt kommt der Schritt, bei dem die Reihenfolge zählt. Laut Installationsanleitung erhält der erste registrierte Benutzer Administratorrechte. Solange Forgejo nur an 127.0.0.1 lauscht und Caddy noch nicht konfiguriert ist, kann das niemand ausser euch sein. Öffnet von eurem Rechner aus einen SSH-Tunnel zum Server:

ssh -L 3000:127.0.0.1:3000 benutzer@euer-server

Ruft dann im Browser http://localhost:3000 auf. Forgejo zeigt beim ersten Aufruf eine Seite mit der Grundkonfiguration. Prüft dort, dass Datenbanktyp SQLite3, Server-Domain, SSH-Port 222 und die Basis-URL https://git.example.ch/ stimmen, und schliesst die Installation ab. Registriert danach sofort euer eigenes Konto. Es wird das Administratorkonto.

Anschliessend sperrt ihr die offene Registrierung, bevor die Instanz von aussen erreichbar wird. Ergänzt in der Compose-Datei unter environment:

      - FORGEJO__service__DISABLE_REGISTRATION=true
      - FORGEJO__service__DEFAULT_KEEP_EMAIL_PRIVATE=true

Die zweite Zeile blendet die E-Mail-Adressen neuer Konten standardmässig aus. Wollt ihr, dass ohne Anmeldung überhaupt nichts sichtbar ist, auch keine öffentlichen Repositories, kommt FORGEJO__service__REQUIRE_SIGNIN_VIEW=true dazu. Übernehmt die Änderung mit:

docker compose up -d

Compose erkennt die geänderte Umgebung und erstellt den Container neu. Weitere Konten legt ihr ab jetzt als Administrator in der Verwaltungsoberfläche an. Schaltet für euer eigenes Konto gleich die Zwei-Faktor-Authentifizierung ein: Forgejo unterstützt laut Codeberg-Dokumentation TOTP und zusätzlich Hardwareschlüssel über WebAuthn, eingerichtet in den Benutzereinstellungen unter Sicherheit. Den dabei angezeigten Wiederherstellungscode legt ihr in euren Passwortmanager.

HTTPS über Caddy

Mit Caddy ist der Reverse Proxy für Forgejo eine Sache von drei Zeilen. Ergänzt in /etc/caddy/Caddyfile den Block, den auch die Forgejo-Dokumentation zum Reverse Proxy zeigt:

git.example.ch {
	reverse_proxy 127.0.0.1:3000
}

Prüfen und neu laden wie gewohnt:

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

Caddy holt das Zertifikat selbst und setzt die Kopfzeilen X-Forwarded-For und X-Forwarded-Proto ohne weiteres Zutun. Eine Obergrenze für die Uploadgrösse setzt Caddy nicht; wer stattdessen nginx benutzt, braucht die in der Forgejo-Dokumentation genannte Zeile client_max_body_size 512M;, sonst scheitern grosse Pushes über HTTPS und Anhänge.

Ein Detail betrifft alle, die später auf Forgejo 17 oder die nächste LTS wechseln. Mit Forgejo 16 hat das Projekt die Voreinstellung für vertrauenswürdige Proxys in Container-Installationen verschärft. Die Release-Notiz nennt als Folge, dass Forgejo eine Anmeldung über Kopfzeilen des Reverse Proxy nicht mehr akzeptiert, wenn diese Funktion eingeschaltet ist, und verlangt eine ausdrückliche Liste mit dem Adressbereich des Container-Netzes. In der Konfiguration heisst der Schlüssel REVERSE_PROXY_TRUSTED_PROXIES im Abschnitt [security]. Wer diese Anmeldung nicht nutzt, wie in dieser Anleitung, ist davon nicht betroffen.

Sitzt der Proxy, ist die Weboberfläche unter https://git.example.ch erreichbar. Das war der unspektakuläre Teil. Wer bis hierhin gekommen ist, hat einen Git-Server, der sich im Browser nicht von einem gemieteten unterscheidet, nur dass ihn niemand mit einer KI-Funktion beglücken wird, um die ihr nicht gebeten habt.

Git über SSH auf Port 222

Damit Git über SSH funktioniert, braucht Forgejo euren öffentlichen Schlüssel. Wer noch keinen hat, findet die Grundlagen in Sicher per SSH einloggen. Hinterlegt den Inhalt eurer ~/.ssh/id_ed25519.pub in Forgejo unter Einstellungen, SSH-/GPG-Schlüssel.

Testet dann die Verbindung mit dem Befehl aus der Forgejo-Dokumentation:

ssh -F /dev/null git@git.example.ch -p 222

Der Parameter -F /dev/null sorgt dafür, dass eure lokale SSH-Konfiguration beim Test keine Rolle spielt. Forgejo antwortet mit einer kurzen Meldung, die euren Benutzernamen nennt, und schliesst die Verbindung wieder. Eine Shell gibt es an dieser Stelle nicht, und das ist richtig so.

Damit ihr nicht bei jedem Befehl den Port angeben müsst, ergänzt ihr auf eurem Rechner die Datei ~/.ssh/config:

Host git.example.ch
    Port 222
    User git
    IdentityFile ~/.ssh/id_ed25519

Ab jetzt funktionieren Klon-Adressen in der Form, die Forgejo selbst anzeigt:

git clone ssh://git@git.example.ch:222/mario/dotfiles.git

Dank des Eintrags in ~/.ssh/config klappt auch die kürzere Schreibweise git@git.example.ch:mario/dotfiles.git.

Wer über HTTPS statt SSH arbeitet und die Zwei-Faktor-Authentifizierung eingeschaltet hat, meldet sich bei Git nicht mit dem Passwort an, sondern mit einem Zugriffstoken, das ihr in den Einstellungen unter Anwendungen erzeugt.

Von GitHub umziehen: Migration und Spiegel

Forgejo kann bestehende Repositories von GitHub, GitLab und anderen Forges übernehmen. Der Weg führt über das Plus-Menü oben rechts und den Eintrag "Neue Migration". Dort wählt ihr GitHub als Quelle und gebt die Adresse des Repositories an.

Für mehr als den nackten Git-Verlauf braucht Forgejo ein persönliches Zugriffstoken von GitHub. Laut Codeberg-Dokumentation zur Migration lassen sich damit auch Metadaten wie Issues, Labels, Wiki, Releases und Meilensteine mitnehmen. Gebt dem Token nur Leserechte und widerruft es nach dem Umzug wieder. Für private Repositories ist es ohnehin nötig, weil Forgejo sonst gar keinen Zugriff hat.

Nicht jeder will GitHub sofort verlassen. Für den Übergang bietet Forgejo zwei Arten von Spiegeln:

• Ein Pull-Spiegel holt regelmässig den Stand eines fremden Repositories in eure Instanz. Er lässt sich nur beim Anlegen eines neuen Repositories einrichten, über dieselbe Migrationsmaske mit dem Häkchen für den Spiegel.
• Ein Push-Spiegel schiebt jeden Stand eures Forgejo-Repositories zu GitHub. Damit wird Forgejo zur führenden Quelle und GitHub zur Kopie. GitHub verlangt dafür ein Token mit dem Recht public_repo, optional zusätzlich workflow.

Beim Push-Spiegel ist die Warnung der Dokumentation ernst zu nehmen: Er schiebt mit Force Push und überschreibt alles, was am Ziel abweichend liegt. Wer auf GitHub noch direkt arbeitet, verliert dort Commits. Die Regel lautet deshalb: Es gibt genau eine Stelle, an der gearbeitet wird, und die andere ist Kopie.

Issues und Labels werden bei einem Pull-Spiegel übrigens nicht mitgespiegelt, wie ein Fehlerbericht im Forgejo-Projekt festhält: Beim Häkchen für den Spiegel sind die Optionen für Issues, Pull Requests und Releases gesperrt, das Projekt führt das als nicht umgesetzte Funktion. Gespiegelt wird der Git-Inhalt. Wer die Diskussionen mitnehmen will, macht eine echte Migration.

Sichern und zurückspielen

Forgejo bringt mit forgejo dump einen eigenen Sicherungsbefehl mit, der alles in ein Archiv packt. Die Upgrade-Anleitung von Forgejo warnt allerdings selbst, dass das Zurückspielen der Datenbank aus diesem Archiv "serious long standing open bugs" hat. Als verlässlichsten Weg empfiehlt sie eine zeitgleiche Momentaufnahme des gesamten Speichers, den Forgejo benutzt.

Mit SQLite und einem einzigen Datenverzeichnis ist genau das einfach: Container anhalten, Verzeichnis archivieren, Container starten.

cd /opt/forgejo
docker compose stop
sudo tar -czf /srv/backup/forgejo-$(date +%F).tar.gz forgejo compose.yml
docker compose start

Die Unterbrechung dauert wenige Sekunden. Weil compose.yml mit im Archiv liegt, enthält die Sicherung auch die komplette Konfiguration. Wer PostgreSQL benutzt, nimmt das Verzeichnis postgres in den tar-Befehl mit auf und erstellt vorher, bei noch laufendem Stack, zusätzlich einen Datenbankauszug, der unabhängig von der PostgreSQL-Version lesbar bleibt:

docker compose exec -T db pg_dump -U forgejo forgejo > /srv/backup/forgejo-db-$(date +%F).sql

Das Zurückspielen ist die Umkehrung: Archiv an denselben Ort entpacken, Eigentümer mit chown -R 1000:1000 prüfen, docker compose up -d. Probiert das einmal auf einer zweiten Maschine aus, bevor ihr es braucht. Warum eine Sicherung, die nie zurückgespielt wurde, wenig wert ist, und wo die zweite Kopie hingehört, steht in Was ist ein gutes Backup: die 3-2-1-Regel erklärt. Den nächtlichen Lauf automatisiert ihr am besten mit einem systemd-Timer statt Cronjob, der euch benachrichtigt, wenn etwas schiefgeht.

Aktualisieren ohne Überraschungen

Innerhalb einer Hauptversion ist ein Update zwei Befehle:

cd /opt/forgejo
docker compose pull
docker compose up -d

Der Tag 15 zieht dabei automatisch die neueste 15.x-Fassung. Mehr Handarbeit verlangt der Wechsel der Hauptversion, bei der LTS-Reihe also im Frühjahr 2027 von 15 auf 19. Die Upgrade-Anleitung nennt dafür diese Reihenfolge:

• Release-Notizen der neuen Version lesen, insbesondere die Abschnitte zu Änderungen mit Bruch.
• Warteschlangen leeren, weil ihr Inhalt laut Dokumentation nicht garantiert rückwärtskompatibel ist.
• Vollständige Sicherung wie oben.
• Tag in compose.yml ändern, dann docker compose pull und docker compose up -d.
• Mit forgejo doctor prüfen, dass keine Probleme gemeldet werden, und die Weboberfläche von Hand durchsehen.

Die beiden Forgejo-Befehle laufen im Container, und zwar nicht als root. Forgejo verweigert das mit der Meldung, es sei "not supposed to be run as root". Die Lösung aus dem Fehlerbericht im Forgejo-Dokumentationsprojekt ist, den Befehl mit der Benutzer-ID aus der Compose-Datei auszuführen:

docker exec -u 1000 forgejo forgejo manager flush-queues
docker exec -u 1000 forgejo forgejo doctor check --all --log-file /tmp/doctor.log

Laut Anleitung dürft ihr Hauptversionen grundsätzlich überspringen. Treten dabei Fehler auf, empfiehlt sie, die Zwischenversionen einzeln zu durchlaufen und jeweils zu prüfen.

Wenn etwas nicht klappt

Der Container startet nicht oder meldet fehlende Schreibrechte. Fast immer gehört das Datenverzeichnis dem falschen Benutzer. Prüft mit ls -ln /opt/forgejo, ob forgejo der ID aus USER_UID gehört, und korrigiert mit sudo chown -R 1000:1000 /opt/forgejo/forgejo.

Die Klon-Adresse zeigt Port 22 statt 222. Die Zeile FORGEJO__server__SSH_PORT=222 fehlt oder wurde nach einer Änderung nicht übernommen. Nach jeder Änderung an der Umgebung gehört ein docker compose up -d dazu, ein blosser Neustart des Containers reicht nicht.

SSH fragt nach einem Passwort für den Benutzer git. Der Schlüssel ist in Forgejo nicht hinterlegt, oder SSH bietet einen anderen Schlüssel an. Mit ssh -v -p 222 git@git.example.ch seht ihr, welcher Schlüssel angeboten wird. Landet die Verbindung dagegen beim SSH-Dienst des Servers statt bei Forgejo, fehlt der Port: Ohne -p 222 oder den Eintrag in ~/.ssh/config klopft Git an Port 22.

Ein Forgejo-Befehl im Container meldet, er dürfe nicht als root laufen. Ihr habt docker exec ohne -u 1000 aufgerufen.

Links in E-Mails oder in der Oberfläche zeigen auf localhost:3000. ROOT_URL fehlt oder ist falsch. Die Dokumentation zum Reverse Proxy weist ausdrücklich darauf hin, dass sonst erzeugte Links kaputtgehen.

Grosse Pushes über HTTPS brechen ab. Ein vorgeschalteter nginx begrenzt die Grösse. Caddy tut das in der Grundeinstellung nicht; liegt zusätzlich ein anderer Proxy oder ein CDN davor, prüft dessen Grenze.

Nach einem Hauptversions-Update fehlen Funktionen oder die Oberfläche wirft Fehler. Zurück auf die Sicherung, alten Tag eintragen, und die Release-Notizen lesen, bevor ihr es erneut versucht. Genau deshalb steht die Sicherung in der Reihenfolge vor dem Update und nicht danach.

Fazit: Forgejo ist der kleinste Schritt weg von GitHub

Ein eigener Git-Server klingt nach Infrastrukturprojekt und ist am Ende ein Container, eine Compose-Datei und drei Zeilen Caddyfile. Forgejo nimmt euch dabei die Arbeit ab, die eine Forge ausmacht, und lässt euch die Entscheidung, wo eure Repositories liegen. Mit der LTS-Reihe hält sich auch der Pflegeaufwand in Grenzen: ein Handgriff pro Jahr für die Hauptversion, dazwischen docker compose pull.

Die Gegenrechnung gehört dazu. Auf GitHub findet euch die Welt, auf eurem Server findet euch zunächst niemand. Für öffentliche Projekte, die von Beiträgen Fremder leben, ist ein Push-Spiegel deshalb oft der ehrlichere Weg als der harte Schnitt. Für alles Private gilt dagegen: Was nie auf einem fremden Server lag, kann dort auch niemand auswerten, herausgeben oder für das Training eines Modells verwenden. Dass Forgejo seit Version 9 unter einer Copyleft-Lizenz steht und von einem gemeinnützigen Verein getragen wird, macht es ausserdem deutlich unwahrscheinlicher, dass euch in drei Jahren dieselbe Geschichte mit einer anderen Firma noch einmal passiert.

Quellen und weiterführende Links

• Forgejo: Installation with Docker
• Forgejo: Installation
• Forgejo: Release Schedule
• Forgejo: Releases
• Forgejo v16.0 is available (16.07.2026)
• Forgejo: Recommended Settings
• Forgejo: Configuration Cheat Sheet
• Forgejo: Reverse Proxy
• Forgejo: Upgrade Guide
• Forgejo: Repository Mirrors (v15.0)
• Forgejo Actions: Overview
• Forgejo: Comparison with Gitea
• Forgejo is now copyleft, just like Git (22.08.2024)
• Forgejo Docs Issue #722: Forgejo doctor can not be run as root in a container
• Forgejo Issue #4962: Pull mirroring does not mirror labels, issues
• Codeberg Documentation: Migrating repositories
• Codeberg Documentation: Setting up two-factor authentication
• Docker Docs: Install the Docker Compose plugin
• Microsoft: Microsoft to acquire GitHub for $7.5 billion (04.06.2018)

The post Forgejo selbst hosten: eigener Git-Server mit Docker appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Google-Suche und DMA: was die Kommission im Juli verlangt hat

Am 23. Juli 2026 hat die Kommission Google mit 890 Millionen Euro gebüsst. 460 Millionen davon betreffen die Suche: Google habe eigene Dienste für Shopping, Hotels, Verkehr und Sportresultate bevorzugt, «including at the top of the search results page or by using enhanced visuals and filters». Die übrigen 430 Millionen betreffen Google Play und sind nicht Thema dieses Beitrags. Laut Pressemitteilung IP/26/1670 hatte Google 60 Tage Zeit, danach drohen Zwangsgelder von bis zu fünf Prozent des weltweiten Tagesumsatzes.

Wichtig für alles Folgende: Der DMA verbietet Selbstbevorzugung. Er schreibt nicht vor, wie eine gute Suchergebnisseite auszusehen hat. Diese Lücke füllt Google selbst — und nutzt sie, wie sich zeigt, auch für die Öffentlichkeitsarbeit.

Was Google am 8. September in der EU-Suche umgebaut hat

Google hat den Umbau am 8. September ausgerollt, knapp zwei Wochen vor Fristende. Die technische Beschreibung steht nicht in einer Pressemitteilung, sondern in Googles Dokumentation für Website-Betreiber. Zwei neue Elemente tragen den Umbau.

Erstens die Aggregator Unit, ein Block für Vergleichsdienste. Sie erscheint laut Google bei Anfragen «related to hotels, flights, long distance trains or buses, products, and local businesses». Der bestplatzierte Vergleichsdienst wird ausgeklappt, weitere lassen sich aus einer Liste wählen. Aufgenommen wird nur, wer von Google als «Vertical Search Service» anerkannt ist und seine Daten per Feed oder Echtzeit-Schnittstelle liefert.

Zweitens die Supplier Unit für direkte Anbieter, also einzelne Hotels, Fluggesellschaften oder Handwerksbetriebe. Für sie braucht es keine Datenlieferung, das normale Crawling genügt. Bedingung ist, dass die Website «must serve users in the EEA».

Dazu kommt, was wegfällt. Laut einer Reuters-Meldung vom 8. September zeigen die Karussells für Hotels, Airlines und Restaurants keine Echtzeitpreise mehr. Die Plattform E-Commerce Germany hat zudem beobachtet, dass die organischen Produktkarussells um den 15. und 16. September aus den Ergebnissen im EWR verschwunden und durch einen Block mit Vergleichsseiten ersetzt worden sind.

Der grösste Qualitätsverlust in 29 Jahren — sagt Google

Google hat den Umbau nicht still vollzogen, sondern laut angekündigt. Nick Fox, bei Google für Suche zuständiger Senior Vice President, sagte gegenüber Reuters: «These changes degrade the user experience for Europeans — boosting online intermediaries at the expense of local businesses, and removing helpful features people rely on every day.» Google spricht vom grössten Qualitätsverlust in der 29-jährigen Geschichte der Suche und nennt einen Rückgang des Direktbuchungsverkehrs zu europäischen Betrieben um 30 Prozent bei früheren DMA-Anpassungen. Diese Zahl stammt von Google selbst und ist unabhängig nicht überprüft.

Ganz falsch ist der Einwand nicht. Auch der Schweizer Branchendienst Hotel Inside beschreibt das Paradox: Wenn Vergleichsportale oben stehen, wird aus einer möglichen Direktbuchung schnell eine vermittelte, und davon profitiert vor allem Booking, das laut der dort zitierten HOTREC-Studie rund 71 Prozent des Marktes der Online-Reisebüros hält. Ein Torwächter wird zurückgedrängt, ein anderer rückt nach. Das ist ein echtes Problem der Umsetzung.

Beim Absender lohnt sich trotzdem ein genauer Blick. Die «hilfreichen Funktionen», deren Verlust Google beklagt, sind exakt jene Flächen, für die die Kommission Google verurteilt hat: Hotelpreise und Produktkarussells aus Googles eigenen Diensten, prominent über allen anderen. Dass ein Konzern die Entfernung seiner eigenen Bevorzugung als Qualitätsverlust bezeichnet, ist ungefähr so überraschend wie ein Wirt, der das Rauchverbot für einen Angriff auf die Gemütlichkeit hält. Es ist vor allem eine Botschaft an die Politik, rechtzeitig vor der Beurteilung durch die Kommission.

Die Frist ist abgelaufen, die Kommission schweigt

Was am 21. September passiert ist, lässt sich schnell beantworten: öffentlich nichts. Die Nachrichtenseite der Kommission zum DMA führt nach dem Bussenentscheid vom 23. Juli bis heute, 28. September, keinen weiteren Eintrag zu Google. Ob die Kommission den Umbau als ausreichend betrachtet, ob sie Zwangsgelder prüft oder ob sie mit Google noch verhandelt, ist nicht bekannt. Die Pressemitteilung vom Juli kündigt lediglich an, die Kommission werde die Umsetzung überwachen und den Dialog fortsetzen, ausdrücklich auch zur Darstellung in AI Overviews und im AI Mode.

Das Schweigen ist bemerkenswert, weil gerade die Frist der Punkt war, der den DMA vom klassischen Kartellrecht unterscheidet. Eine Uhr, die abläuft, ohne dass jemand auf sie schaut, ist keine Durchsetzung, sondern Dekoration. Wer gewinnt, hängt jetzt davon ab, ob Brüssel Googles Umbau prüft oder Googles Pressearbeit.

Google-Suche in der Schweiz: gilt nur im EWR, und da gehört die Schweiz nicht dazu

Beide Dokumentationsseiten von Google nennen denselben Geltungsbereich: den Europäischen Wirtschaftsraum. Zur Aggregator Unit heisst es: «People in European Economic Area (EEA) countries who are searching for things like 'hotels near me' may notice that the experience has changed.» Die Schweiz gehört nicht zum EWR. Das EDA hält fest: «1992 lehnte die Schweiz den Beitritt zum EWR-Abkommen in einer Volksabstimmung ab.» Vertragsstaaten sind neben den EU-Mitgliedern Norwegen, Island und Liechtenstein.

Daraus folgt nach Googles eigener Darstellung ein Grenzverlauf mitten durchs Rheintal. Wer in Vaduz nach einem Hotel sucht, gehört zum EWR; wer in Buchs SG dieselbe Anfrage stellt, nicht. Ob Google den EWR in der Praxis genau so abgrenzt, haben wir nicht selbst geprüft, und Reuters zitiert Google mit dem leicht abweichenden Satz, Nutzer ausserhalb der EU seien nicht betroffen. Für die Schweiz macht beides keinen Unterschied: Sie liegt weder in der EU noch im EWR.

Auch die Schweizer Fachpresse ist sich nicht sicher. Das IT-Magazine schrieb am 10. September: «Wie sich die Änderungen auf die Schweiz auswirken, muss sich erst noch zeigen. Oft gelten vergleichbare Anpassungen in der EU auch hierzulande.» Die Dokumentation sagt das Gegenteil, und die Erfahrung dieses Sommers ebenfalls.

Zweimal dieselbe Grenze, zweimal verliert die Wahlfreiheit

Im Juli hat Google den Auswahlbildschirm für die Suchmaschine auf Android in der Schweiz abgeschafft. Die WEKO hat in ihrer Medienmitteilung vom 14. Juli genau die Grenze beschrieben, die jetzt wieder auftaucht: Google habe die Funktion «in der Schweiz abgeschafft, während sie im Europäischen Wirtschaftsraum (EWR) weiterhin verfügbar ist». Eine neue Mitteilung zu dieser Vorabklärung gibt es bis heute nicht.

Jetzt also der zweite Fall mit umgekehrtem Vorzeichen. Beim Auswahlbildschirm verloren Schweizer Nutzer etwas, das es im EWR weiter gibt. Bei der Suche behalten sie etwas, das es im EWR nicht mehr gibt: Googles eigene Hotelpreise und Produktkarussells an erster Stelle. Wer das als Glück empfindet, weil die Suche hierzulande «besser» bleibt, übernimmt Googles Lesart. Die andere Lesart lautet: In der Schweiz darf Google weiterhin tun, wofür es in der EU mit 460 Millionen Euro gebüsst wurde.

Beide Fälle beruhen auf derselben Mechanik, und sie ist die gleiche wie im Vorgängerartikel: Wo eine Pflicht besteht, baut Google um. Wo keine besteht, bleibt alles so, wie es für Google am günstigsten ist — mal durch Wegnehmen, mal durch Stehenlassen. Die Schweiz ist in diesem Bild nicht Zuschauerin, sondern Kontrollgruppe.

Eine praktische Randnotiz verdient trotzdem Erwähnung: Schweizer Hotels verschwinden nicht aus der neuen EWR-Suche. Die Supplier Unit verlangt nur, dass die Website Nutzer im EWR bedient — was für jedes Hotel mit Gästen aus Deutschland, Österreich oder Italien zutrifft. Wie sie dort im Vergleich zu Booking abschneiden, entscheidet allerdings wieder Googles Algorithmus.

Was noch offen ist

• Die Beurteilung der Kommission. Ob der Umbau den Entscheid vom 23. Juli erfüllt, hat Brüssel bis heute nicht gesagt. Erst eine Stellungnahme oder ein Zwangsgeldverfahren zeigt, ob die 60-Tage-Frist mehr war als eine Zahl in einer Pressemitteilung.
• Die Rolle von Booking. Wenn Vergleichsdienste die frei gewordenen Flächen besetzen, profitiert vor allem ein Anbieter, den die EU selbst als Torwächter führt und dem die Kommission am 28. September ein eigenes Merkblatt gewidmet hat. Ob die Kommission das in ihrer Beurteilung berücksichtigt, ist offen.
• Die AI Overviews. Die Kommission hat angekündigt, auch über die Darstellung in Googles KI-Antworten zu sprechen. Wird dort Googles eigener Inhalt bevorzugt, verschiebt sich die Selbstbevorzugung nur um ein Stockwerk nach oben.
• Die Grenze in der Praxis. Ob Liechtenstein tatsächlich die neue Ansicht bekommt und die Schweiz ausnahmslos die alte, ist nur über Googles Dokumentation belegt, nicht über einen Test. Wer im Rheintal wohnt, kann das mit zwei Suchanfragen diesseits und jenseits der Grenze nachprüfen.
• Die WEKO. Die Vorabklärung zum Auswahlbildschirm läuft seit dem 14. Juli, ohne Frist und ohne Sanktionsmöglichkeit. Zur Suche hat die Schweiz kein Verfahren, und das KomPG regelt, wie im Vorgängerartikel beschrieben, die Inhalte nach dem Muster des DSA, nicht den Markt.

Unabhängig davon, wie Brüssel entscheidet, bleibt die einfachste Form von Wahlfreiheit in der Schweiz dieselbe wie vorher: Die Standardsuchmaschine lässt sich von Hand ändern, und unsere Übersicht zu den Alternativen zur Google-Suche nennt die Kandidaten. Wer grundsätzlicher ansetzen will, findet im Ratgeber zum Schutz der Privatsphäre den Einstieg.

Fazit: Die Schweiz bleibt Googles Kontrollgruppe

Der Umbau der Google-Suche zeigt zweierlei. Erstens wirkt der DMA: Innert 60 Tagen hat Google Flächen geräumt, die die Kommission im Juli beanstandet hatte. Zweitens ist Wirkung nicht dasselbe wie Erfolg. Ob Nutzer in der EU jetzt die bessere Wahl haben oder nur einen anderen Vermittler vor die Nase gesetzt bekommen, ist offen, und die Kommission trägt mit ihrem Schweigen nichts zur Klärung bei.

Für die Schweiz ist die Lage dagegen eindeutig. Ob Google eine Wahlmöglichkeit streicht oder eine verurteilte Praxis beibehält, hängt hier allein davon ab, was Google gerade nützt. Im Juli war es das Wegnehmen, im September das Stehenlassen. Ein Land, das in beiden Richtungen nur zusieht, reguliert nicht das Falsche. Es reguliert in dieser Frage gar nicht.

Quellen und weiterführende Links

• 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)
• Europäische Kommission: DMA Latest News, Stand 28. September 2026
• Google Search Central: Aggregator unit in Google Search, zuletzt aktualisiert 18. September 2026
• Google Search Central: Supplier unit in Google Search, zuletzt aktualisiert 18. September 2026
• Reuters (via The Star): Google warns of lower quality as it revamps Europe search results to avoid EU fines, 8. September 2026
• E-Commerce Germany: Google product carousels disappear from search in the EEA
• Hotel Inside: Brüssel gegen Google – und Booking gewinnt?, 15. September 2026
• IT-Magazine: Grösster Qualitätsverlust in 29 Jahren – Google moniert neue EU-Regeln, 10. September 2026
• EDA: Europäische Freihandelsassoziation (EFTA) und Europäischer Wirtschaftsraum (EWR)
• WEKO: Das Sekretariat der WEKO ermittelt gegen Google, 14. Juli 2026

The post Google-Suche nach dem DMA: die Schweiz bleibt draussen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dieser Blog hat im Februar beschrieben, wie Palantir die Polizeidatenbanken der Länder zusammenführt, und vor einer Woche, wie der EU KIDS Act Anonymität im Netz zum begründungspflichtigen Sonderfall macht. Beides handelte von Daten, die schon irgendwo lagen. Am Kottbusser Tor entstehen sie erst, und zwar über Leute, die nichts anderes tun, als über einen Platz zu gehen. Dieser Kommentar schaut nicht auf die Frage, ob Kameras dort hängen dürfen — das tun sie seit Jahren —, sondern darauf, was das Gesetz mit den Bildern erlaubt, nachdem die Software sie gesehen hat.

KI-Videoüberwachung Berlin: was am Kottbusser Tor läuft

Die Grundlage ist § 24e des Berliner Allgemeinen Sicherheits- und Ordnungsgesetzes, kurz ASOG, in der Fassung nach der Polizeirechtsreform. Absatz 4 erlaubt der Polizei, die Bildaufnahmen von kriminalitätsbelasteten Orten "auch automatisiert auszuwerten". Ausgeschlossen sind die automatisierte biometrische Fernidentifizierung und die Nutzung der Bilder für das Training solcher Programme. Gesichter werden also nicht abgeglichen. Ausgewertet wird, was Menschen tun.

Was das konkret heisst, steht in der Antwort der Senatsverwaltung für Inneres und Sport auf eine schriftliche Anfrage des Grünen-Abgeordneten Vasili Franco (Drucksache 19/26970). An den kriminalitätsbelasteten Orten, im Behördendeutsch kbO, "detektiert das System Gewaltvorfälle (z. B. schlagende oder tretende Personen) sowie Notsituation (z. B. bewegungslos liegende Personen)". Im Normalbetrieb bleibt der Bildschirm in der Leitstelle schwarz. Erst wenn die Software eine vorher definierte Situation erkennt, schaltet er sich ein und zeigt die Szene, eine Einsatzkraft bewertet sie und entscheidet über weitere Massnahmen. Der Senat nennt das Black-Screen-Prinzip und Human-in-the-Loop.

Der Fahrplan steht in derselben Antwort. Nach dem Kottbusser Tor folgt die Warschauer Brücke bis Ende 2026, Alexanderplatz und Görlitzer Park sind für 2027 geplant. Allein für das Kottbusser Tor beziffert der Senat die Investitionskosten auf 1.888.000 Euro, davon 770.000 Euro für Hardware, und die Betriebskosten bis einschliesslich 2029 auf rund 349.000 Euro pro Jahr. Den Zuschlag hat laut netzpolitik.org die adesso SE bekommen, die Software zur Verhaltenserkennung stammt von der Staige GmbH, an der adesso beteiligt ist.

Berlin ist damit nicht Pionier, sondern Nachzügler. In Mannheim läuft eine algorithmenbasierte Bildauswertung seit Dezember 2018, entwickelt vom Fraunhofer IOSB, Hamburg hat am Hansaplatz nachgezogen, und der Bundestag hat im Juli mit dem neuen Bundespolizeigesetz automatisierte Videoanalyse für Bahnhöfe beschlossen. Neu an Berlin ist etwas anderes: Das Land hat seinem Polizeigesetz nicht nur die Auswertung beigebracht, sondern auch gleich geregelt, wie die Software aus den Bildern lernen darf.

Warum der Verzicht auf Gesichtserkennung so bequem ist

Bevor es um das Training geht, lohnt ein Blick auf die Grenze, die das Gesetz so sorgfältig zieht. Der europäische AI Act verbietet in Artikel 5 Absatz 1 Buchstabe h "the use of 'real-time' remote biometric identification systems in publicly accessible spaces for the purposes of law enforcement", mit eng gefassten Ausnahmen. Dieses Verbot gilt nach Artikel 113 seit dem 2. Februar 2025. Eine Software, die erkennt, dass jemand zuschlägt, identifiziert niemanden in Echtzeit. Sie fällt nicht darunter.

Das ist kein Vorwurf an den Berliner Gesetzgeber, sondern eine Beschreibung der Lage. Die einzige rote Linie, die das europäische Recht für Videoanalyse im öffentlichen Raum zieht, verläuft entlang der Identität. Alles, was sich an Verhalten ablesen lässt, ohne einen Namen dazuzuschreiben, liegt diesseits davon. Der Ausschluss der Gesichtserkennung in § 24e ist deshalb weniger eine Selbstbeschränkung als die Beschreibung dessen, was ohnehin verboten ist. Das Gesetz verzichtet auf das, was es nicht haben darf, und nimmt sich den Rest.

Wie weit dieser Rest reicht, zeigt ein zweites Berliner Projekt.

Vom Faustschlag zum Fotografieren: der Katalog im Objektschutz

Neben den kriminalitätsbelasteten Orten will die Polizei KI-Videotechnik auch dort einsetzen, wo sie Gebäude schützt. Das Leistungsverzeichnis für dieses Projekt, das netzpolitik.org veröffentlicht hat, nennt als Erprobungsorte das Alte Stadthaus in der Klosterstrasse, also den Sitz der Innenverwaltung, das Berliner Rathaus und das Abgeordnetenhaus. Stationäre Kameras, mobile Kamerasysteme und ein optionales Drohnenmodul sollen nach denselben Alarmregeln arbeiten.

Gefordert sind dort unter anderem das Erkennen von beschädigten Zäunen, zurückgelassenen Gegenständen über 30 Zentimeter und unzulässig abgestellten Fahrzeugen. Unter der Überschrift "Ungewöhnliche Objektablagen und Verhaltensauffälligkeiten" steht ausserdem:

• "Langes Verharren/Umhergehen ohne Anlass"
• "Langanhaltendes Fotografieren"
• "Wiederholtes Erscheinen (ohne biometrische Identifikation)"

Nach der Auswertung von netzpolitik.org sind diese Punkte keine Pflichtanforderung. Sie stehen aber im Dokument, mit dem die Polizei beschreibt, was sie von einem Anbieter haben möchte. Bemerkenswert ist, dass sie in der Senatsantwort an Vasili Franco nicht vorkommen. Dort erkennt das System im Objektschutz Zonenverletzungen, Vandalismus und zurückgelassene Gegenstände — also genau die harmlos klingenden Punkte. Ob die Verhaltensauffälligkeiten im Zuschlag enthalten sind, geht aus den öffentlich zugänglichen Unterlagen nicht hervor.

Wer vor dem Roten Rathaus lange fotografiert, war bisher Tourist, Architekturstudent oder Hochzeitsgesellschaft. Im Leistungsverzeichnis ist er eine Verhaltensauffälligkeit. Das ist nicht nur eine Pointe, es ist die eigentliche Frage an jede Verhaltenserkennung: Wer definiert "ohne Anlass"? Eine Software kennt keinen Anlass. Sie kennt Dauer, Wege und Wiederholung. Was davon als auffällig gilt, legt jemand fest, bevor die Kamera läuft, und der Mensch am Bildschirm sieht danach nur noch die Fälle, die diese Festlegung ausgesiebt hat. Die Juristin Petra Sussner hat das im Verfassungsblog so formuliert: "Wo Ermächtigungsgrundlagen im Einzelfall wenig Aufschluss über Anlass und Grenzen des behördlichen Handlungsspielraums geben, greifen rasch alltägliche Stereotype."

Und dann ist da der dritte Punkt. "Wiederholtes Erscheinen" zu erkennen, ohne jemanden biometrisch zu identifizieren, verlangt, dieselbe Person an einem anderen Tag wiederzuerkennen, ohne zu wissen, wer sie ist — an Kleidung, Statur, Gang. Wie das technisch gelöst werden soll und ob ein solches Wiedererkennen nicht selbst auf biometrischen Merkmalen beruht, beantwortet das Dokument nicht. Die Klammer "ohne biometrische Identifikation" ist dort eine Zusicherung, keine Beschreibung.

Anonymisiert, pseudonymisiert, personenbezogen: die Treppe in § 42d

Jetzt zum Kern. Die Polizeirechtsreform hat dem ASOG einen Paragrafen gegeben, den es in dieser Form in kaum einem anderen Polizeigesetz gibt: § 42d, "Training und Testung von KI-Systemen". Absatz 1 erlaubt Polizei und Feuerwehr, rechtmässig gespeicherte personenbezogene Daten "auch über die vorgesehene Speicherdauer hinaus weiterzuverarbeiten", wenn das nötig ist, um KI-Systeme zu trainieren und zu testen. Diskriminierende Algorithmen sollen dabei "weder herausgebildet noch verwendet werden".

Absatz 2 regelt, in welcher Form die Daten ins Training gehen, und er ist als Treppe gebaut. Zuerst sind sie zu anonymisieren. Kann der Zweck mit anonymisierten Daten nicht erreicht werden, oder ist die Anonymisierung "nur mit unverhältnismässigem Aufwand möglich", sind sie zu pseudonymisieren. Und wenn auch das nicht reicht: "dürfen personenbezogene Daten verwendet werden". Spätestens nach zwei Jahren sind sie zu löschen oder unumkehrbar zu anonymisieren, "es sei denn, ihre Weiterverarbeitung ist nach anderen Rechtsvorschriften zulässig".

Absatz 3 regelt, wer mitarbeiten darf. Zuerst Auftragsverarbeiter, wenn die Polizei es selbst nicht oder nur mit unverhältnismässigem Aufwand kann. Und wenn auch das nicht reicht, "dürfen Polizei und Feuerwehr personenbezogene Daten auch an Dritte zu dem in Satz 1 genannten Zweck übermitteln", sofern diese ihren Sitz in der EU oder in einem Schengen-assoziierten Staat haben.

Jede Stufe dieser Treppe hat eine Begründung, die für sich genommen vernünftig klingt. Zusammen ergeben sie eine Regel, deren Ausnahme immer dann greift, wenn die Regel stört. Wer einmal versucht hat, Videomaterial wirklich zu anonymisieren, weiss, wo das hinführt: Ein Trainingsbild, auf dem nichts mehr zu erkennen ist, taugt nicht zum Training. Der "unverhältnismässige Aufwand" ist bei Video kein Sonderfall, er ist der Normalfall.

Der Senat beschreibt die Praxis in der Antwort auf eine Anfrage des Linken-Abgeordneten Niklas Schrader (Drucksache 19/26879) beruhigend. Für das Nachtraining würden "wirksam bzw. irreversibel anonymisierte Datenbestände verwendet", bei denen eine Reidentifizierung ausgeschlossen sei — "es sei denn, eine Anonymisierung steht den Zwecken der Testung oder des Trainings entgegen". Das Nachtraining sei vertraglich mit dem Auftragnehmer vereinbart, finde ausschliesslich auf Servern im Rechenzentrum der Polizei statt, und "die Datenhoheit verbleibt uneingeschränkt bei der Polizei Berlin". Die Rohvideos würden einen Monat gespeichert, die abgeleiteten Daten in einer Ereignisdatenbank, "insbesondere Ereignisklasse, Konfidenzwert und Szenenbeschreibungsvektoren", nach den Vorgaben des ASOG.

Das ist die Beschreibung einer Absicht, nicht einer Grenze. Die Grenze setzt das Gesetz, und das Gesetz erlaubt mehr, als der Senat heute zu tun behauptet. Zum Vergleich: In Mannheim werden die Aufnahmen laut Polizei "grundsätzlich für maximal 72 Stunden gespeichert und anschliessend automatisch gelöscht". In Berlin darf, was die Software einmal gesehen hat, über jede Speicherfrist hinaus bis zu zwei Jahre im Trainingsbestand bleiben — und länger, wenn eine andere Vorschrift es erlaubt.

Wer zu Unrecht auffällt, wird zum Lehrmaterial

Welche Bilder dafür infrage kommen, sagt das Leistungsverzeichnis im Objektschutz ohne Umschweife. In Abschnitt 4.1.6 werden "die von der KI falsch als Alarm detektierten Ereignisse (False-Positive) für das Nachtrainieren der KI im Rahmen der rechtlichen Zulässigkeit zur Verfügung gestellt". Unter dem Stichwort Genauigkeit verlangt dasselbe Dokument eine Gesamterkennungsgenauigkeit von mindestens 95 Prozent und hält fest, die "maximale durchschnittliche Fehlalarmrate soll nicht höher als 25 % über alle Szenarien liegen". Wird die Fehlalarmrate als Anteil an allen Alarmen gelesen, darf im Schnitt jeder vierte falsch sein.

Das ist aus Sicht eines Entwicklers folgerichtig. Ein Klassifikator wird besser, wenn er lernt, wo er sich geirrt hat, und die Irrtümer sind die wertvollsten Daten, die ein Betrieb überhaupt liefert. Aus Sicht der Leute auf dem Platz sieht das anders aus. Für das Nachtraining nennt das Leistungsverzeichnis nicht die Fälle, die die Software richtig erkannt hat, sondern ausdrücklich die, bei denen sie danebenlag. Das sind denkbarerweise Leute, die sich stürmisch umarmen, hektisch nach dem Bus rennen oder lange auf jemanden warten — genau die Art Bewegungen, bei denen der CCC fragt, ob sie als verdächtig eingestuft werden. Wer von der Software zu Unrecht verdächtigt wird, liefert ihr damit die Nachhilfe.

Dass es ohne echte Daten schwer wird, zeigt ausgerechnet Mannheim. netzpolitik.org hat dort im Oktober 2025 recherchiert und berichtet, dass gestellte Situationen beim Training eine wichtige Rolle spielen, weil echte Vorfälle auf den Mannheimer Plätzen zu selten sind. Staige hat die Berliner Software laut Senat "ausschliesslich mit synthetisch erzeugten Daten" trainiert. Genau deshalb ist § 42d kein Nebenparagraf. Er ist die Stelle, an der synthetische Daten gegen echte getauscht werden dürfen.

Die Berliner Datenschutzbeauftragte Meike Kamp hat im Interview mit netzpolitik.org vom 22. September gesagt: "Meine Behörde war bei der Auswahl der Software und beim Training nicht eingebunden." Und: "Falschpositive Alarme werden sich nicht vollständig ausschliessen lassen." Beide Sätze zusammen beschreiben die Lage genauer als jede Pressemitteilung. Die Fehlalarme kommen sicher, und die Aufsicht war nicht dabei, als festgelegt wurde, was mit ihnen geschieht.

Polizei und Auftragnehmer benoten sich selbst

Bleibt die Frage, woran Berlin am Ende messen will, ob sich das alles gelohnt hat. Die Antwort an Vasili Franco ist eindeutig: "Eine Beauftragung einer externen wissenschaftlichen Studie zur Evaluation der KI-Videoschutzmassnahme ist derzeit nicht vorgesehen." Die Bewertung erfolge "gemeinsam durch die Polizei Berlin und den Auftragnehmer". Dazu kommt die gesetzliche Pflicht aus § 24e Absatz 1, die Auswirkungen auf die Kriminalität am jeweiligen Ort mindestens alle zwei Jahre zu untersuchen. Ob die Kriminalität an einem Platz sinkt, weil eine Software mitschaut, oder weil die Polizei dort ohnehin häufiger Streife fährt, lässt sich so nicht trennen.

Die Erfahrungen der Vorgänger machen das nicht besser. Die Polizei Mannheim hat netzpolitik.org nach sieben Jahren Betrieb mitgeteilt, der "für das Projekt ablesbare Erfolg besteht in der stetigen Weiterentwicklung des Systems und kann zum derzeitigen Projektstand nicht mit Kennzahlen dargestellt werden". Den Satz würde jedes Start-up unterschreiben, das seine dritte Finanzierungsrunde erklären muss. Zum Hamburger Versuch am Hansaplatz im Sommer 2023 hat der Blog marx.wtf, auf den auch der Chaos Computer Club verweist, die per Informationsfreiheitsanfrage herausgegebenen Evaluationsunterlagen ausgewertet: Die Zahl der Detektionen betrug laut Bericht "etwa eine pro Stunde", als polizeilich relevant eingestuft wurden über den gesamten Versuch elf Ereignisse.

Der CCC hat daraus im März ein knappes Urteil gemacht. Sprecher Matthias Marx: "Automatisierte Verhaltensüberwachung ist teures, aber gefährliches Sicherheitstheater." Das lässt sich polemisch finden. Widerlegt hat es bisher keine der beteiligten Polizeibehörden, und keine hat eine unabhängige Prüfung angekündigt, die es widerlegen könnte.

Was an der Gegenseite stimmt

Drei Argumente der Befürworter verdienen eine ernsthafte Antwort, weil sie nicht falsch sind.

Erstens: Das Black-Screen-Prinzip ist datensparsamer als klassische Videoüberwachung. Bisher konnten Beamte am Kottbusser Tor jede Szene live sehen, jetzt sehen sie nur noch die, die die Software meldet. Das Fraunhofer IOSB wirbt genau damit: "A person's face or identity does not play a role, only their behavioural patterns." Das stimmt für den Bildschirm in der Leitstelle. Es stimmt nicht für den Datenbestand dahinter. Was der Mensch nicht sieht, sieht die Software vollständig, und § 42d regelt, dass sie es behalten darf. Das Versprechen gilt dem Blick, nicht der Speicherung.

Zweitens: Eine Software, die eine bewegungslos liegende Person erkennt, kann Leben retten. Auch das stimmt, und niemand, der das Kottbusser Tor kennt, wird bestreiten, dass dort Notlagen vorkommen. Nur rechtfertigt dieser Anwendungsfall weder den Katalog im Objektschutz noch das Training mit Fehlalarmen. Wer Notfälle erkennen will, braucht keinen Alarm für "langanhaltendes Fotografieren" vor dem Rathaus. Die guten Anwendungsfälle werden hier als Türöffner für die weniger guten benutzt.

Drittens: Die Polizei hat zu wenig Personal. Polizeipräsidentin Barbara Slowik Meisel sagt zum Start, nur mit modernen Technologien werde es "in der Zukunft gelingen, den Schutz der Menschen in dieser Stadt zu gewährleisten". Das Problem ist real. Aber die Rechnung geht nur auf, wenn die Software Arbeit spart. Bei etwa einem Alarm pro Stunde und elf relevanten Ereignissen in knapp zwei Monaten, wie in Hamburg, spart sie keine Arbeit, sie verteilt sie um: vom Beobachten zum Aussortieren. Und jeder aussortierte Fehlalarm ist, siehe oben, ein Datensatz mehr.

Und die Schweiz?

Das ASOG gilt in Berlin, nicht in Bern. Trotzdem gibt es zwei Berührungspunkte. Der erste steht in § 42d Absatz 3 selbst: Auftragsverarbeiter und Dritte, an die Trainingsdaten gehen, müssen ihren Sitz in der EU "oder in einem Schengen-assoziierten Staat" haben. Die Schweiz ist ein solcher Staat. Ein Schweizer Anbieter könnte also Berliner Polizeivideos zum Training bekommen, ohne dass das Gesetz daran etwas auszusetzen hätte.

Der zweite ist die eigene Gesetzgebung. Der Zürcher Kantonsrat hat Anfang 2026 ein revidiertes Polizeigesetz verabschiedet, das der Polizei KI-gestützte Analysesysteme erlaubt, die laut der Digitalen Gesellschaft "sensible Personendaten aus verschiedenen Quellen zusammenführen, analysieren und daraus Aussagen oder Wahrscheinlichkeiten über Personen ableiten". Die Organisation hat am 24. August 2026 zusammen mit anderen Beschwerde beim Bundesgericht eingereicht. Verhaltenserkennung auf Video ist dort nicht der Gegenstand, das Zürcher Gesetz zielt eher auf das, was Palantir in Deutschland tut. Aber die Richtung ist dieselbe, und die Schweiz ist an den AI Act nicht gebunden. Die eine rote Linie, die das EU-Recht immerhin zieht, gibt es hier nicht einmal als Untergrenze.

Wer sich für Kameras im eigenen Garten interessiert, findet die Schweizer Rechtslage für Private in unserem Kaufratgeber zur Überwachungskamera ohne Cloud. Für die Polizei gelten andere Regeln, und sie sind gerade dabei, sich zu verschieben.

Was das für euch heisst

Gegen eine Kamera am Kottbusser Tor könnt ihr als Einzelne wenig ausrichten, und eine Liste mit Alibi-Massnahmen hilft hier niemandem. Was bleibt, ist Einordnung.

Die Bilder, die dort entstehen, gehören nicht euch, und ihr erfahrt nicht, ob eure in einem Trainingsbestand landen. Selbst eine Auskunftsanfrage bei der Polizei setzt voraus, dass ihr wisst, wonach ihr fragt; bei einer Szene, die nach einem Fehlalarm ins Nachtraining gegangen ist, wisst ihr das nicht. Das ist der Unterschied zu der Überwachung, gegen die ihr euch zu Hause selbst schützen könnt — etwa gegen einen Fernseher, der mitschaut. Im öffentlichen Raum gibt es keinen Stecker, den ihr ziehen könnt.

Entschieden wird das deshalb nicht am Platz, sondern vor Gericht. Die Fraktionen von Grünen und Linken im Abgeordnetenhaus haben am 28. August 2026 beim Berliner Verfassungsgerichtshof eine abstrakte Normenkontrolle gegen das neue Polizeigesetz eingereicht. Angegriffen sind unter anderem die KI-gestützte Videoüberwachung und das Training von KI-Systemen mit Polizeidaten samt Weitergabe an Dritte. Mit einer Entscheidung rechnet netzpolitik.org frühestens in ein bis zwei Jahren, einen Eilantrag gibt es nicht. Bis dahin läuft die Software, und sie lernt.

Für Leser in der Schweiz ist Berlin damit eine Vorschau. Der Zürcher Fall liegt beim Bundesgericht, und wie dort über KI-Analysen entschieden wird, bestimmt mit, ob Verhaltenserkennung auf Video hier später als nächster Schritt gilt oder als Grenze.

Fazit: Berlins Verhaltensscanner lernt an denen, die er zu Unrecht verdächtigt

Die KI-Videoüberwachung am Kottbusser Tor ist kein Skandal im Sinne eines Rechtsbruchs. Sie hat eine Rechtsgrundlage, sie identifiziert niemanden, sie zeigt dem Menschen nur, was sie meldet. Gerade deshalb lohnt es, genau hinzusehen, was das Gesetz neben der Auswertung noch erlaubt. § 42d ASOG macht aus einem Überwachungsinstrument ein Trainingsprogramm, und das Leistungsverzeichnis für den Objektschutz sagt offen, welche Bilder es am meisten braucht: die Fehlalarme. Wer unschuldig auffällt, wird nicht einfach aussortiert, sondern verwertet — anonymisiert, wenn es geht, pseudonymisiert, wenn nicht, und personenbezogen, wenn auch das nicht reicht.

Der Satz "Die KI meldet, der Mensch entscheidet" stimmt. Er ist nur unvollständig. Vollständig lautet er: Die KI meldet, der Mensch entscheidet, und wenn der Mensch entscheidet, dass die KI falsch lag, lernt die KI an euch. Evaluiert wird das von denen, die es verkauft haben, und denen, die es gekauft haben. Ein System, das seine Irrtümer an Unbeteiligten korrigiert und seine Erfolge selbst benotet, gehört nicht in einen Probebetrieb, sondern vor ein Gericht. Dort liegt es jetzt immerhin.

Quellen und weiterführende Links

• Polizei Berlin: Berlin startet mit KI-gestütztem Videoschutz, 24.09.2026
• Abgeordnetenhaus Berlin, Drucksache 19/26970: Schriftliche Anfrage von Vasili Franco zur KI-Videoüberwachung an kriminalitätsbelasteten Orten und öffentlichen Gebäuden
• Abgeordnetenhaus Berlin, Drucksache 19/26879: Schriftliche Anfrage von Niklas Schrader zum KI-Training, Antwort vom 08.09.2026
• § 24e ASOG Bln: Datenerhebung an kriminalitätsbelasteten Orten (Wortlaut)
• § 42d ASOG Bln: Training und Testung von KI-Systemen (Wortlaut)
• Polizei Berlin: Leistungsverzeichnis zum Projekt zur Erprobung KI-gestützter Videotechnik im Objektschutz (veröffentlicht von netzpolitik.org)
• netzpolitik.org: Kameras und Drohnen in Berlin: Was Verhaltensscanner erkennen sollen, 07.09.2026
• netzpolitik.org: Interview mit Meike Kamp, 22.09.2026
• netzpolitik.org: Verhaltensscanner in Mannheim, 18.10.2025
• netzpolitik.org: Linke und Grüne ziehen vor den Verfassungsgerichtshof, 28.08.2026
• netzpolitik.org: Neues Bundespolizeigesetz, 10.07.2026
• Polizeipräsidium Mannheim: Infos zum Videoschutz in Mannheim
• Fraunhofer IOSB: Intelligent video surveillance
• marx.wtf: Der Hansaplatz-Versuch war kein Erfolg, 24.12.2024
• Chaos Computer Club: Automatisierte Verhaltensüberwachung: Gefährlichen Mumpitz einstellen, 06.03.2026
• Petra Sussner, Verfassungsblog: Try harder hilft selten, 08.01.2026
• AI Act Service Desk der EU-Kommission: Artikel 5, verbotene Praktiken
• AI Act Service Desk der EU-Kommission: Artikel 113, Inkrafttreten und Geltung
• Digitale Gesellschaft: «Minority Report» in Zürich, Beschwerde gegen das neue Polizeigesetz, 24.08.2026

The post KI-Videoüberwachung Berlin: Ihr seid das Trainingsmaterial appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Chatkontrolle ist damit endgültig das Gesetz, das nie beschlossen wird und nie verschwindet. Wie die freiwillige Variante im Juli per Verfahrenstrick zurückkam, steht in unserem Beitrag EU beschliesst Chatkontrolle Light im Eilverfahren; die Unterscheidung zwischen Chatkontrolle 1.0 und 2.0 ist dort ebenfalls erklärt. Hier geht es um das, was seither dazugekommen ist, und um die Frage, was am Dienstag entschieden werden soll.

Chatkontrolle-Trilog am 29. September: was feststeht

Ein Trilog ist die informelle Verhandlungsrunde, in der Vertreter der drei EU-Institutionen einen gemeinsamen Gesetzestext aushandeln. Protokolle werden nicht veröffentlicht, die Öffentlichkeit erfährt vom Ergebnis erst, wenn es feststeht. Dass am 29. September verhandelt wird, belegt ein internes Papier der irischen Ratspräsidentschaft an die Mitgliedstaaten: Das Ratsdokument 11956/26 vom 10. September 2026, eingestuft als „LIMITE" und von Agence Europe öffentlich gemacht, kündigt den sechsten Trilog „at the Council premises on 29 September 2026" an.

Patrick Breyer, früherer EU-Abgeordneter der Piraten und derjenige, der den Begriff Chatkontrolle geprägt hat, beschreibt die Lage auf seiner laufend aktualisierten Themenseite so: „Am Dienstag, den 29. September findet ein potenziell letzter und entscheidender Trilog statt." Und weiter: „Die EU-Unterhändler stehen unter massivem Druck, einen ‚faulen Kompromiss' zu schliessen, der verdachtslose Massenscans unserer Chats dauerhaft zementieren würde." Verhandlungsführer der Kommission ist Innenkommissar Magnus Brunner.

Seit Juli wieder erlaubt: die freiwillige Chatkontrolle

Der Juli-Beitrag endete mit dem Hinweis, dass der Rat noch zustimmen muss. Das hat er getan: Am 23. Juli 2026 hat der Rat die Übergangsverordnung wieder in Kraft gesetzt. Anbieter dürfen damit erneut freiwillig nach Darstellungen sexuellen Kindesmissbrauchs suchen, und zwar „until 3 April 2028". Laut EDRi gilt die neue Ausnahme seit dem 31. Juli 2026.

Eine Einschränkung hat das Parlament durchgesetzt, und sie ist die wichtigste: Ende-zu-Ende-verschlüsselte Kommunikation ist ausgenommen. Der Rat zitiert die Änderung wörtlich, ausgeschlossen sind Dienste, „to which end-to-end encryption is, has been or will be applied". EDRi hält fest, dass die beiden Änderungsanträge ausdrücklich auch gegen Client-Side-Scanning schützen. Für die Übergangszeit heisst das: Signal bleibt draussen, unverschlüsselte Direktnachrichten grosser Plattformen nicht.

Das verschiebt die Kräfte im Trilog. Die Übergangslösung, die das Parlament im März abgelehnt hatte, gilt jetzt wieder bis 2028. Breyer hatte schon im Juli gewarnt, dass die Regierungen keinen Anreiz haben, sich auf das Konzept des Parlaments einzulassen, solange ihr Status quo immer wieder verlängert wird. Seit dem 31. Juli liegt dieser Status quo für die nächsten zwanzig Monate fest.

Der Kompromiss der Präsidentschaft: zwei Spuren

Wie die irische Präsidentschaft die Verordnung zuschneiden will, hat Agence Europe am 23. September 2026 beschrieben. Der Vorschlag teilt Inhalte in zwei Gruppen:

• Öffentliche Inhalte — also alles, was ohnehin jeder sehen kann — sollen per Aufdeckungsanordnung durchsucht werden können, allerdings nur nach bereits bekanntem Material, ausdrücklich um eine allgemeine Überwachungspflicht zu vermeiden.
• Private Kommunikation — Chats, Direktnachrichten, private Cloud-Ordner — soll weiter freiwillig durchsucht werden, gestützt auf die Ausnahme von der ePrivacy-Richtlinie. Und zwar nach bekanntem und neuem Material sowie nach Anbahnungsversuchen gegenüber Kindern, dem sogenannten Grooming.

Die Reihenfolge ist bezeichnend: Dort, wo ohnehin alles öffentlich ist, gibt es enge Regeln. Dort, wo es um private Nachrichten geht, gibt es die weiteste Befugnis.

Der Unterschied zwischen bekanntem und neuem Material ist dabei nicht nur juristisch. Bekanntes Material lässt sich mit einer Liste von Prüfwerten bereits identifizierter Aufnahmen abgleichen. Neues Material und Grooming dagegen setzen voraus, dass eine Software private Bilder und Unterhaltungen inhaltlich beurteilt, die sie nie zuvor gesehen hat. Das Parlament verlangt deshalb laut Agence Europe, automatisierte Erkennung auf bekanntes Material zu beschränken und dafür die Indikatoren-Datenbank des geplanten EU-Zentrums zu verwenden.

Suchplan statt Verdacht

Der Kern des Streits ist die Frage, wer eine Durchsuchung auslösen darf und für wie lange. Das Ratsdokument 11956/26 nennt als möglichen Kompromiss die „authorisation of search plans for a period of time rather than on a case-by-case basis" — also die Genehmigung von Suchplänen für einen Zeitraum statt im Einzelfall. Der Antrag eines Anbieters könne dabei „the technologies used and other relevant safeguards" enthalten. Was dem Rat dabei am wichtigsten ist, steht im selben Papier: „the most important aspect for the Council is effective detection and removal of content online as provided for through the voluntary regime".

Pikant ist, dass der Plan auch in der Position des Parlaments vorkommt. Es verlangt laut Agence Europe, dass jede Suche einen Plan mit den eingesetzten Technologien und Schutzvorkehrungen voraussetzt und von einer Justiz- oder unabhängigen Verwaltungsbehörde genehmigt und beaufsichtigt wird. Der Rat übernimmt den Begriff, verschiebt aber den Gegenstand: Durchsucht werden sollen laut Agence Europe „specific parts of a service or individual users". Nicht mehr nur einzelne Nutzer also, sondern wahlweise einzelne Nutzer oder ganze Teile eines Dienstes.

Breyer nennt das auf seiner Seite „Schein-Targeting" und fasst den Vorschlag so zusammen: „Sie wollen Behörden dauerhaft erlauben, auf Antrag eines Anbieters ‚Suchpläne' für ‚Teile eines Dienstes' zu genehmigen." Was ein „Teil eines Dienstes" ist, beantragt der Anbieter; genehmigen muss es die Behörde — nur eben nicht mehr im Einzelfall, sondern für einen Zeitraum. Die Direktnachrichten einer Plattform sind ebenso ein Teil des Dienstes wie ihre Gruppenchats. Ein richterlicher Durchsuchungsbefehl nennt eine Person. Ein Suchplan nennt eine Funktion. Das ist kein Durchsuchungsbefehl für eine Wohnung, sondern eine Dauerbewilligung für das ganze Treppenhaus.

Was sonst noch auf dem Tisch liegt

Das Ratsdokument listet als ergänzende Massnahmen „safety by design, facilitating user flagging, metadata analysis and behaviour patterns and age verification systems". Zwei davon verdienen Aufmerksamkeit. Metadaten und Verhaltensmuster fallen auch dort an, wo Inhalte verschlüsselt sind — ihre Analyse wäre also der Weg, auf dem auch verschlüsselte Dienste wieder in den Blick geraten. Warum Metadaten oft mehr verraten als Inhalte, haben wir in Metadaten bei Messengern ausführlich beschrieben. Und die Altersverifikation, die der Rat laut EDRi für riskante Dienste verpflichtend machen will, ist dieselbe Art Werkzeug, die die Kommission parallel im EU KIDS Act vorsieht. Das Parlament lehnt sie in der CSA-Verordnung ab.

Offen ist, ob die Verschlüsselung in der dauerhaften Verordnung so geschützt bleibt wie in der Übergangslösung. Laut netzpolitik.org galt der Ausschluss verschlüsselter Inhalte im Juni nur als „vorläufig" vereinbart. Ob das nach dem Dienstag noch gilt, steht in keinem öffentlich bekannten Dokument.

Was ihr bis Dienstag tun könnt

Ein Trilog ist nicht öffentlich, aber die Verhandler des Parlaments sind gewählt und erreichbar. Viel Zeit bleibt nicht:

• Schreibt euren EU-Abgeordneten, oder ruft an. Das Werkzeug auf fightchatcontrol.eu hilft dabei, die eigenen Abgeordneten zu kontaktieren, und verfolgt die Positionen der Mitgliedstaaten. Betrieben wird es nach eigener Angabe von einem dänischen Softwareentwickler ohne Parteibindung, der keine Spenden annimmt.
• Nennt drei konkrete Punkte, wie Breyer sie formuliert: Das Parlament soll bei seinem Mandat bleiben — Anordnungen nur gegen konkret Verdächtige —, pauschale Suchpläne ablehnen und keine Schlupflöcher für freiwillige Massenscans zulassen.
• Setzt bei den grossen Fraktionen an. Breyer empfiehlt, vor allem Abgeordnete der konservativen EVP und der Sozialdemokraten anzusprechen, weil an ihnen das Ergebnis hängt.
• Lest in der Schweiz mit. Die Schweiz verhandelt nicht mit, eure Abgeordneten sitzen nicht in Strassburg. Die Dienste, um die es geht, sind aber dieselben, die ihr benutzt — teilt die Information mit Bekannten in der EU.
• Schützt eure eigene Kommunikation, unabhängig vom Ausgang: Ende-zu-Ende-verschlüsselte Messenger sind von der freiwilligen Chatkontrolle ausgenommen. Welche sich eignen, steht in unserem Juli-Beitrag.

Fazit: Ein Suchplan ist kein Verdacht

Die Chatkontrolle 2.0 kommt nicht mehr als Scanpflicht für alle zurück, sondern in Einzelteilen: freiwilliges Scannen, das bis 2028 bereits gilt, Suchpläne, die ganze Teile eines Dienstes umfassen dürfen, Metadatenanalyse für das, was verschlüsselt bleibt, und eine Altersprüfung für Dienste, die als riskant gelten. Jedes Einzelteil lässt sich als massvoll verkaufen. Zusammen ergeben sie das, was das Parlament seit 2023 ablehnt: die Durchsuchung privater Kommunikation ohne konkreten Verdacht.

Der Unterschied zwischen dem Parlament und dem Rat lässt sich deshalb auf eine einzige Frage zurückführen, die am Dienstag beantwortet werden soll: Beginnt eine Durchsuchung bei einem Menschen, gegen den etwas vorliegt, oder bei einem Dienst, auf dem viele Menschen sind? Alles andere ist Verpackung. Dass diese Frage hinter verschlossenen Türen entschieden wird, gehört leider zur Tradition des Verfahrens — ebenso wie der Umstand, dass die Öffentlichkeit vom Ergebnis voraussichtlich aus einem geleakten Dokument erfährt.

Quellen und weiterführende Links

• Rat der EU: Dokument 11956/26 (LIMITE), 10.09.2026, via Agence Europe — Stand der Verhandlungen, sechster Trilog am 29.09.2026, Suchpläne für einen Zeitraum, ergänzende Massnahmen
• Agence Europe, 23.09.2026: Irish Presidency seeks to refine approach between public and private content — die zwei Spuren, die Positionen von Rat und Parlament
• Patrick Breyer: Chatkontrolle — laufend aktualisierte Themenseite mit Termin, Einschätzung „Schein-Targeting" und Handlungsaufruf
• Rat der EU, 23.07.2026: Interim measure now reinstated — Wiederinkraftsetzung der Übergangsverordnung bis 03.04.2028, Ausschluss verschlüsselter Kommunikation
• EDRi, 04.08.2026: The Chat Control 1.0 saga — Geltung ab 31.07.2026, Schutz auch gegen Client-Side-Scanning
• EDRi, 25.02.2026: Chat Control is in the final stretch — Positionen von Rat und Parlament zu Scanpflicht, Verschlüsselung und Altersverifikation
• netzpolitik.org, 12.06.2026: Trilog zur Chatkontrolle geht in entscheidende Phase — interne Dokumente, vorläufiger Ausschluss verschlüsselter Inhalte
• Fight Chat Control — Werkzeug zum Kontaktieren der EU-Abgeordneten

The post Chatkontrolle-Trilog: Suchplan statt Verdacht appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung führt von der leeren Maschine bis zur übernommenen Google-Mediathek: Voraussetzungen, Installation mit Docker Compose, die Einstellungen des ersten Tages, der Import eines Google-Takeout-Archivs ohne Datenverlust, der Zugriff von aussen und die Sicherung. Wer Immich nur ausprobieren will, findet auf yourdevice.ch eine laufende Immich-Instanz als kostenlosen Dienst. Und wer seine Bilder schon in einer Nextcloud hat, wirft vorher einen Blick auf Memories als Foto-App für Nextcloud — manchmal ist die kleinere Lösung die richtige.

Immich selbst hosten: was ihr bekommt, und was ihr nicht bekommt

Immich ist eine Galerie mit Server: Die Bilder liegen als gewöhnliche Dateien auf einer Festplatte, die Metadaten in einer Postgres-Datenbank, darüber sitzt eine Weboberfläche nach dem Vorbild von Google Fotos — Zeitleiste, Alben, Karte, Personen, Suche nach Bildinhalten. Die mobilen Apps laden neue Aufnahmen automatisch hoch, und das ist der eigentliche Grund, warum so ein Aufbau im Alltag durchhält. Ein Foto-Archiv, das Handarbeit verlangt, wird nach drei Wochen nicht mehr befüllt.

Was Immich ausdrücklich nicht ist: eine Sicherung. Die Projektdokumentation ist an dieser Stelle unmissverständlich und schreibt zum Pilotbetrieb der eigenen Datenbanksicherung: „The database only contains metadata and user information. You must setup manual backups of the images and videos stored in UPLOAD_LOCATION.“ Immich selbst empfiehlt in seiner Anleitung zu Sicherung und Wiederherstellung eine 3-2-1-Strategie. Wer die einzige Kopie seiner Familienfotos in einen Dienst schiebt, den er gerade selbst zusammengesteckt hat, hat kein Archiv, sondern ein Hobby mit Risiko.

Aktuell ist die Reihe 3.x: Version 3.0.0 erschien am 1. Juli 2026, die jüngste Fassung 3.2.0 am 10. September 2026. Mit 3.0 hat sich die Mindestanforderung an den Prozessor geändert, und die Versionsnummer steht in der Konfigurationsdatei, die ihr gleich anlegt.

Was die Maschine mitbringen muss

Die Anforderungsseite des Projekts nennt konkrete Zahlen, und sie sind ernst gemeint. Als Betriebssystem empfiehlt das Projekt „Linux or *nix 64-bit operating system (Ubuntu, Debian, etc)“; Windows und macOS gelten wegen der schwächeren Docker-Unterstützung als Notlösung. Beim Speicher stehen „Minimum 6GB, recommended 8GB“ — mit 4 GB läuft Immich nur dann, wenn das maschinelle Lernen abgeschaltet ist. Beim Prozessor sind es „Minimum 2 cores, recommended 4 cores“.

Zwei Punkte werden regelmässig übersehen. Erstens verlangt Immich ab Version 3 auf amd64 die Mikroarchitektur x86-64-v2 — das betrifft nur Rechner, die älter als etwa 2012 sind, aber wer einen ausgemusterten Bürorechner zum Fotoserver machen wollte, prüft das vorher. Zweitens gehört das Datenverzeichnis der Datenbank auf lokalen Speicher, am besten auf eine SSD: Netzwerkfreigaben sind nicht unterstützt. Das Dateisystem muss Benutzer- und Gruppenrechte kennen; NTFS und alles aus der FAT-Familie fallen damit aus.

Beim Platzbedarf rechnet ihr mit einem Zuschlag: Vorschaubilder und umgewandelte Videos lassen die Mediathek laut Dokumentation um 10 bis 20 Prozent wachsen. Bei 400 GB Bildern sind das bis zu 80 GB, die niemand einplant und die dann mitten im ersten Import die Platte füllen.

Die vier Container, aus denen Immich besteht

Immich wird nicht als ein Programm installiert, sondern als vier zusammenarbeitende Container. Der Blick in die offizielle docker-compose.yml zeigt, wer welche Aufgabe hat:

• immich-server — die Anwendung selbst, samt Weboberfläche und Schnittstelle. Sie ist das einzige Element, das einen Port nach draussen öffnet: 2283. Eingebunden ist genau ein Verzeichnis, nämlich UPLOAD_LOCATION als /data.
• immich-machine-learning — Gesichtserkennung, Objekterkennung und die Suche nach Bildinhalten. Dieser Container hält keine Nutzerdaten, sondern nur die heruntergeladenen Modelle im Volume model-cache. Er ist derjenige, der den Arbeitsspeicher frisst.
• redis — die Warteschlange für Hintergrundaufträge. Der Dienst heisst weiterhin so, das Abbild ist inzwischen aber valkey, der freie Abzweig von Redis nach dessen Lizenzwechsel.
• database — Postgres, allerdings kein gewöhnliches: Das Abbild trägt den Namen postgres:14-vectorchord… und bringt die Vektor-Erweiterungen mit, ohne die es keine Ähnlichkeitssuche und keine Gesichtsgruppierung gibt. Deshalb lässt sich hier auch nicht einfach ein bestehender Postgres-Server aus dem Netz verwenden.

Diese Aufteilung ist der Grund, warum die Sicherung später aus zwei Teilen besteht — und warum die Frage, welcher Teil des Aufbaus ersetzbar ist, vor dem ersten Import geklärt sein sollte.

Immich installieren: zwei Dateien, ein Befehl

Voraussetzung ist Docker samt Compose-Erweiterung aus dem offiziellen Docker-Repository, nicht aus den Distributionspaketen — das Projekt weist ausdrücklich darauf hin, dass Fehler beim Start meist daran liegen. Wie die Einrichtung unter Debian, Ubuntu und Linux Mint abläuft, steht in unserem Beitrag zu den Docker-Grundlagen und der Installation. Wichtig ist ausserdem die Schreibweise: docker compose mit Leerzeichen. Das alte docker-compose mit Bindestrich wird nicht mehr unterstützt.

Legt ein eigenes Verzeichnis an und holt die beiden Dateien, die das Projekt für jede Version bereitstellt:

mkdir -p /opt/immich && cd /opt/immich
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Die docker-compose.yml bleibt unangetastet. Bearbeitet wird nur die .env, und dort genügen fünf Zeilen:

UPLOAD_LOCATION=/srv/immich/library
DB_DATA_LOCATION=/srv/immich/postgres
IMMICH_VERSION=v3
DB_PASSWORD=EinLangesPasswortOhneSonderzeichen
TZ=Europe/Zurich

UPLOAD_LOCATION ist das Verzeichnis, in dem später alle Originale liegen. Es darf auf einer grossen Platte oder einem eingebundenen Speicher liegen. DB_DATA_LOCATION ist das Datenverzeichnis von Postgres und gehört, wie oben beschrieben, auf lokalen Speicher. Beide Pfade werden nach dem ersten Start nicht mehr geändert, ohne die Datenbank umzuziehen.

Bei DB_PASSWORD gilt eine Einschränkung, die in der Dokumentation nur als Nebensatz steht und trotzdem Installationen zerlegt: erlaubt sind ausschliesslich die Zeichen A–Z, a–z und 0–9. Ein Passwort mit Dollarzeichen oder Klammern führt zu einer Datenbank, die nicht startet, und zu einer Fehlermeldung, die das Problem nicht nennt. Nehmt eine lange Folge aus Buchstaben und Zahlen.

IMMICH_VERSION steht in der Beispieldatei auf v3. Das ist ein mitwachsendes Kennzeichen: Bei jedem docker compose pull kommt die neueste Fassung der Reihe 3.x. Wer das nicht will, schreibt eine feste Version hinein, etwa v3.2.0. Für den ersten Aufbau ist v3 richtig; sobald der Server ernsthaft benutzt wird, ist eine feste Version die ruhigere Variante.

Danach folgt der eigentliche Start:

docker compose up -d
docker compose logs -f immich-server

Der erste Start dauert länger als erwartet, weil die Datenbank ihr Schema anlegt und der Lerndienst seine Modelle herunterlädt. Erscheint eine Fehlermeldung zu start_interval im Abschnitt der Datenbank, läuft auf der Maschine eine Docker-Engine älter als Version 25; dann wird diese Zeile auskommentiert.

Der erste Aufruf und das Administratorkonto

Die Oberfläche erreicht ihr unter http://<IP-der-Maschine>:2283. Dort führt die Schaltfläche Getting Started zur Registrierung. Entscheidend ist der Satz aus der Dokumentation: „The first user to register will be the admin user.“ Wer den Port erreichbar macht, bevor er sich selbst registriert hat, verschenkt sein Administratorkonto an den ersten Besucher. Registriert euch also zuerst, und öffnet erst danach den Zugang von aussen.

Weitere Konten für Familie oder Mitbewohner legt ihr unter Administration > Users an. Ein vergessenes Administratorpasswort lässt sich laut FAQ über den Befehl reset-admin-password im Container immich-server zurücksetzen.

Die Einstellungen, die vor dem ersten Import gehören

Das Speicher-Template

Unter Administration > Settings > Storage Template legt ihr fest, wie Immich die Dateien auf der Platte ablegt. Die Vorgabe lautet Year/Year-Month-Day/Filename.Extension, die Funktion muss aber erst eingeschaltet werden. Der Sinn dahinter ist Unabhängigkeit: Eine nach Jahr und Datum sortierte Ordnerstruktur bleibt auch dann lesbar, wenn Immich eines Tages nicht mehr startet. Ohne Template liegen die Dateien unter technischen Kennungen, die ohne Datenbank nichts aussagen.

Ändert ihr das Template später, gilt es zunächst nur für neue Dateien; ein eigener Wartungsauftrag überträgt es auf den Bestand. Es ist trotzdem angenehmer, das vor dem Import der ersten 40'000 Bilder zu entscheiden.

Maschinelles Lernen dosieren oder abschalten

Gesichtserkennung und Inhaltssuche sind der Teil, der Rechenzeit und Arbeitsspeicher verlangt. Die FAQ beschreibt zwei Stufen: „Machine learning can be disabled under Administration > Settings > Machine Learning Settings, either entirely or by model type.“ Damit laufen keine Aufträge mehr — der Container startet aber weiterhin und belegt Speicher. Wer ihn ganz loswerden will, kommentiert den Abschnitt immich-machine-learning in der docker-compose.yml aus.

Bei 4 GB Arbeitsspeicher ist das der Unterschied zwischen „läuft“ und „läuft nicht“. Auch auf grösseren Maschinen lohnt es sich, die Modelle beim ersten grossen Import abzuschalten: Sonst konkurrieren Import und Analyse um dieselben Kerne.

Die App auf dem Telefon

Ohne App bleibt ein Fotoserver eine Ablage. Die Anleitung des Projekts zur Nacharbeit nach der Installation nennt vier Bezugsquellen: App Store, Google Play, die APK-Datei aus den GitHub-Releases und Obtainium sowie das F-Droid-Repository von FUTO. Für Geräte ohne Google-Dienste ist der Weg über die APK-Datei oder Obtainium der naheliegende.

Beim Anmelden wird nicht ein Konto bei einem Anbieter eingetragen, sondern die Adresse des eigenen Servers, also http://<IP-der-Maschine>:2283. Danach wählt ihr im Sicherungsbereich der App aus, welche Ordner des Telefons hochgeladen werden sollen — Kamera ja, der Ordner mit den heruntergeladenen Bildern aus Chatgruppen vermutlich nein — und schaltet die Sicherung ein. Der erste Durchlauf läuft am besten über Nacht und im WLAN.

Die Google-Fotos-Mediathek übernehmen

Jetzt zum Teil, an dem die meisten Umzüge scheitern. Ein Google-Fotos-Export ist keine Ordnerstruktur mit Bildern, sondern ein Archiv mit Bildern und einer zweiten Datei je Bild, in der die eigentlichen Informationen stehen. Wer nur die Bilder hochlädt, bekommt eine Mediathek ohne Aufnahmedaten, ohne Orte und ohne Alben — technisch vollständig, inhaltlich entkernt.

Schritt eins: das Takeout-Archiv anfordern

Der Export läuft über den Google Datenexport. Google beschreibt den Weg selbst so: Seite aufrufen, bei allen Produkten das Häkchen entfernen, die ihr nicht braucht, und nur Google Fotos stehen lassen. Danach wählt ihr Dateityp und Grösse. Nehmt ZIP, nicht TGZ, und als maximale Archivgrösse einen Wert, den euer Dateisystem und euer Download verkraften — bei 50 GB Grösse bekommt ihr wenige riesige Dateien, bei 2 GB viele kleine.

Zwei Angaben aus der Google-Hilfe sind für die Planung wichtig: Der Export kann „wenige Minuten oder auch einige Tage“ dauern, und die fertigen Archive „laufen ungefähr nach 7 Tagen ab“, wobei ein Archiv nur fünfmal heruntergeladen werden kann. Wer den Export am Freitagabend anstösst und dann in die Ferien fährt, fängt danach von vorne an.

Warum die Bilder nicht einfach hochgeladen werden

Neben jedem Bild liegt im Archiv eine JSON-Datei. Die Dokumentation von immich-go beschreibt, was dort steht: der ursprüngliche Dateiname, das Aufnahmedatum als Zahl in Sekunden, die GPS-Koordinaten, ob das Bild im Papierkorb lag und ob es aus einer Partnerfreigabe stammt. Alben sind im Archiv als eigene Ordner abgebildet. Vieles davon fehlt in den Bilddateien selbst, weil Google beim Export nicht alles zurückschreibt.

Dazu kommen die bekannten Eigenheiten des Exports, die das Projekt offen benennt: Bilder sind „duplicated with no apparent logic“ über mehrere Teilarchive verteilt, bearbeitete Fassungen haben manchmal keine JSON-Datei, und unbenannte Alben landen im selben Ordner — „Therefore it's impossible to rebuild original albums“. Ein Import, der das ignoriert, erzeugt Dubletten und Alben, die niemand wiedererkennt.

Das offizielle Kommandozeilenwerkzeug von Immich hilft hier nicht weiter, und das sagt es selbst: In der Dokumentation zur Immich-CLI steht „If you are looking to import your Google Photos takeout, we recommend this community maintained tool immich-go“. Die Bastellösung ist hier also der offiziell empfohlene Weg.

Schritt zwei: der Import mit immich-go

immich-go beschreibt sich als „An alternative to the immich-CLI command that doesn't depend on nodejs installation. It tries its best for importing google photos takeout archives.“ Es ist ein einzelnes übersetztes Programm, das ihr als fertige Datei für Linux, macOS, Windows und FreeBSD aus den Releases herunterladet — keine Abhängigkeiten, keine Installation.

Gebraucht wird ein API-Schlüssel aus der Weboberfläche, unter Account Settings > API Keys. Die Hinweise zur guten Praxis empfehlen einen eigenen Schlüssel mit nur den nötigen Rechten, und ihn nicht fest in ein Skript zu schreiben.

Erst ein Probelauf, der nichts schreibt:

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=EUER_API_SCHLUESSEL \
  --dry-run \
  /srv/takeout/takeout-*.zip

Sieht die Ausgabe plausibel aus, folgt der echte Durchlauf. Die Archive bleiben dabei gepackt, entpacken ist nicht nötig:

./immich-go upload from-google-photos \
  --server=http://localhost:2283 \
  --api-key=EUER_API_SCHLUESSEL \
  --manage-raw-jpeg=StackCoverRaw \
  --manage-burst=Stack \
  --pause-immich-jobs=true \
  /srv/takeout/takeout-*.zip

Die Optionen der Reihe nach: --manage-raw-jpeg=StackCoverRaw fasst RAW- und JPEG-Fassung derselben Aufnahme zu einem Stapel zusammen, statt zwei Einträge anzulegen. --manage-burst=Stack macht dasselbe mit Serienaufnahmen. --pause-immich-jobs=true hält die Hintergrundaufträge während des Imports an, was bei grossen Sammlungen empfohlen wird — der Server soll erst einlesen und danach analysieren.

Bricht der Vorgang ab, weil das Netz weg ist oder die Platte voll, startet ihr denselben Befehl einfach erneut: Laut Dokumentation erkennt das Werkzeug bereits vorhandene Dateien und überspringt sie. Einzelne Alben lassen sich mit --from-album-name="Ferien 2023" gezielt holen, und für Bilder, die nicht aus Google Fotos kommen, gibt es upload from-folder mit --folder-as-album=FOLDER.

Der erste Import einer grossen Mediathek braucht Stunden bis Tage. Lasst danach die Hintergrundaufträge durchlaufen, bevor ihr das Ergebnis beurteilt: Eine Zeitleiste mit halben Vorschaubildern ist kein Fehler, sondern eine Warteschlange.

Bestehende Ordner einbinden, statt sie zu kopieren

Wer seine Bilder schon sortiert auf einem NAS hat, will sie nicht ein zweites Mal hineinkopieren. Dafür gibt es externe Bibliotheken: Immich liest ein Verzeichnis, das ihr in den Container einbindet, und legt die Dateien nicht selbst an.

Der Zusatz in der Compose-Datei sieht so aus, und der Schalter am Ende ist der wichtige:

services:
  immich-server:
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /mnt/nas/fotoarchiv:/mnt/media/fotoarchiv:ro

Die Dokumentation erklärt dazu: „The ro flag at the end only gives read-only access to the volumes. This will disallow the images from being deleted in the web UI, or adding metadata to the library.“ Danach legt ihr unter Administration > External Libraries eine Bibliothek an und tragt als Importpfad den Pfad innerhalb des Containers ein, hier also /mnt/media/fotoarchiv. Importpfade werden rekursiv durchsucht, und mit Ausschlussmustern wie **/*.tif oder **/Raw/** lassen sich Dateitypen und ganze Unterordner auslassen.

Drei Eigenschaften solltet ihr kennen, bevor ihr das produktiv nutzt. Ein Suchlauf läuft standardmässig einmal täglich, der Zeitplan ist einstellbar. Verschwindet eine Datei auf der Platte, wandert der Eintrag beim nächsten Durchlauf in den Papierkorb von Immich und wird nach 30 Tagen endgültig entfernt. Und alles, was ihr in Immich an einem externen Bild ergänzt — Beschreibung, Schlagwörter, Personen —, bleibt in der Datenbank und wird nicht in die Datei zurückgeschrieben.

Von aussen erreichbar machen

Port 2283 direkt ins Internet zu stellen ist keine gute Idee, schon weil dann alles unverschlüsselt läuft. Der saubere Weg führt über einen Reverse Proxy mit eigenem Zertifikat; wie das mit Caddy in wenigen Zeilen gelingt, steht in unserer Anleitung zum Caddy Reverse Proxy mit automatischem HTTPS. Für Immich genügt dort ein Block dieser Art:

fotos.example.ch {
    reverse_proxy http://127.0.0.1:2283
    request_body {
        max_size 50GB
    }
}

Die Seite des Projekts zum Reverse Proxy nennt drei Punkte, an denen es sonst hakt. Erstens die Obergrenze für Uploads: Für nginx steht dort client_max_body_size 50000M, und wer sie zu klein setzt, bekommt genau bei den grossen Videos einen Fehler. Zweitens die Zeitgrenzen, die auf 600 Sekunden gehören — proxy_read_timeout 600s und Geschwister. Drittens die Weiterleitung für WebSockets über Upgrade und Connection "upgrade"; ohne sie lädt die Oberfläche, aktualisiert sich aber nie. Caddy bringt die WebSocket-Weiterleitung von sich aus mit, die Zeitgrenzen und die Uploadgrösse müsst ihr setzen.

Wer keinen öffentlichen Zugang braucht, nimmt stattdessen ein VPN und öffnet gar keinen Port — für einen Server, den nur die eigene Familie benutzt, die ruhigere Lösung.

Sichern: zwei Teile, zwei Verfahren

Immich trennt Daten und Metadaten, und genau so wird gesichert. Die Datenbank hält Pfade, Alben, Personen und Benutzer; die Dokumentation stellt klar: „Immich stores file paths and user metadata in the database. It does not scan the library folder, so database backups are essential.“ Ein Auszug entsteht so:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backup/immich-dump.sql.gz

Auf der Dateiseite sind laut Projekt UPLOAD_LOCATION/library, /upload und /profile die kritischen Verzeichnisse; empfohlen wird, UPLOAD_LOCATION vollständig zu sichern, „but only the original content is critical“. Vorschaubilder und umgewandelte Videos baut Immich bei Bedarf neu.

Zwei Regeln dazu. Erstens: Das Datenverzeichnis von Postgres wird nicht als Ordner kopiert. Ein solcher Abzug führt beim Zurückspielen zu Konflikten, und die Dokumentation beschreibt als Ausweg, DB_DATA_LOCATION zu löschen und die Datenbank neu aufzusetzen — was ohne gültigen Auszug bedeutet, dass alle Alben und Personen weg sind. Zweitens die Reihenfolge: Am besten wird der Container immich-server während der Sicherung angehalten. Ist das nicht möglich, sichert zuerst die Datenbank und danach die Dateien.

Beides lässt sich einrichten und dann vergessen. Wie ein solcher Auftrag mit einem systemd-Timer statt eines Cronjobs läuft und sich bei einem Fehlschlag von selbst meldet, haben wir separat beschrieben — gerade bei Sicherungen ist die Benachrichtigung bei Misserfolg der halbe Nutzen.

Aktualisieren, ohne Überraschungen

Ein Update besteht aus zwei Befehlen im Verzeichnis der Compose-Datei:

docker compose pull
docker compose up -d

Was dabei ankommt, entscheidet IMMICH_VERSION. Steht dort v3, holt ihr jeweils die neueste Fassung der Reihe. Vor jedem Sprung gehört ein Blick in die Veröffentlichungshinweise, und zwar aus einem konkreten Grund: Beim Sprung auf 3.0.0 waren die Änderungen mit Bruch überwiegend Schnittstellensachen, das Projekt schreibt dazu, „many of the breaking changes are updates to API endpoints and only affect third-party tools“. Für die Weboberfläche und die Apps war das unkritisch — für Skripte und Fremdwerkzeuge nicht.

Die Fassung 3.2.0 vom 10. September 2026 bringt unter anderem gemeinsame Personengruppen über Benutzergrenzen hinweg. Der Hinweis dazu ist unbedingt zu lesen, bevor die Funktion eingeschaltet wird: Sie verlangt ein Zurücksetzen der Gesichtserkennung für alle beteiligten Benutzer, und dabei gehen die vergebenen Namen und Geburtsdaten verloren. Eine Funktion, die Arbeit von Wochen löscht, gehört nicht in einen Feierabend-Klick.

Worauf ihr achten solltet

Die Fallen bei diesem Aufbau sind selten technisch schwierig, aber teuer, wenn sie erst nach dem Import auffallen:

• Registriert euch zuerst selbst. Das erste Konto wird Administrator. Der Port gehört erst danach nach draussen.
• Nur Buchstaben und Zahlen im Datenbankpasswort. Sonderzeichen in DB_PASSWORD führen zu einer Datenbank, die ohne verwertbare Meldung nicht startet.
• DB_DATA_LOCATION nicht auf eine Netzwerkfreigabe legen. Das ist ausdrücklich nicht unterstützt, und der Schaden zeigt sich erst unter Last.
• Das Speicher-Template vor dem ersten Import einschalten. Nachträglich geht es, verlangt aber einen Wartungsauftrag über den gesamten Bestand.
• Takeout-Archive niemals ohne Werkzeug hochladen. Ohne Auswertung der JSON-Dateien fehlen Datum, Ort und Alben — und das lässt sich später nur mit einem neuen Export nachholen.
• Platz für den Zuschlag einplanen. Vorschaubilder und umgewandelte Videos kommen mit 10 bis 20 Prozent obendrauf.
• Die Sicherung einmal zurückspielen. Ein Datenbankauszug, der noch nie eingelesen wurde, ist eine Vermutung.
• Externe Bibliotheken mit :ro einbinden. Ein Schreibzugriff auf das gewachsene Archiv ist ein Risiko, das keinen Vorteil bringt.

Erst ausprobieren, dann selbst aufsetzen

Bevor ihr eine Maschine aufsetzt, eine Platte einplant und einen Sicherungsauftrag schreibt, lässt sich die wichtigste Frage auch günstiger klären: Passt Immich überhaupt zu der Art, wie ihr eure Fotos verwaltet? Dafür betreiben wir unter unseren Free Services eine eigene Instanz, die ihr kostenlos nutzen könnt — immich.yourdevice.ch, mit 3 GB Speicher gratis für alle. Konto anlegen, App aufs Telefon, ein paar hundert Bilder hochladen.

Was ihr dort an einem Abend lernt, kann diese Anleitung nicht beantworten: ob euch die Zeitleiste liegt, ob die Suche nach Bildinhalten in eurer Sammlung tatsächlich trifft, ob die Gesichtserkennung eure Familie auseinanderhält und ob die App auf eurem Telefon zuverlässig sichert. Alles, was oben Platz braucht — Arbeitsspeicher, Speicherplatz, Reverse Proxy, Sicherung —, stellt sich dabei nicht, weil wir es übernehmen. Kein Tracking, keine Profilbildung, keine Weitergabe an Werbenetzwerke; der Dienst läuft nach denselben Regeln wie alles andere hier.

Und wenn ihr euch danach für den eigenen Server entscheidet, war die Testmediathek kein verlorener Aufwand: immich-go zieht nicht nur aus einem Google-Takeout um, sondern auch von einer Immich-Instanz zur nächsten. Die drei Gigabyte sind als Probe gedacht und nicht als Archiv — für fünfzehn Jahre Familienfotos braucht es die eigene Platte. Dafür steht der Rest dieser Anleitung.

Fazit: Immich ersetzt Google Fotos, aber kein Backup

Der Aufbau selbst ist erstaunlich unspektakulär: zwei heruntergeladene Dateien, fünf Zeilen Konfiguration, ein Befehl. Alles, was in dieser Anleitung Platz braucht, liegt davor und danach — die Frage, ob die Maschine reicht, die Entscheidung über das Speicher-Template, der Umzug der Google-Mediathek, die Sicherung. Wer diese vier Punkte vor dem ersten Bild klärt, hat einen Dienst, der jahrelang läuft. Wer sie überspringt, hat eine Zeitleiste voller Bilder mit Aufnahmedatum von letztem Dienstag.

Der wichtigste Satz steht dabei im Projekt selbst und nicht in dieser Anleitung: Die Datenbanksicherung deckt die Metadaten ab, für die Bilder und Videos seid ihr zuständig. Mit der Kontrolle über die eigenen Erinnerungen kommt die Verantwortung für die zweite Kopie — kein Nachteil des Selbsthostens, sondern dessen ehrlichere Variante. Bei Google lag die zweite Kopie auch nie bei euch, nur hat dort niemand darüber gesprochen.

Habt ihr Immich schon im Einsatz, oder einen Takeout-Import hinter euch, der anders verlief als beschrieben? Schreibt es in die Kommentare.

Quellen und weiterführende Links

• Immich: Requirements — Arbeitsspeicher, Kerne, x86-64-v2 ab Version 3, Dateisysteme und der Hinweis gegen Netzwerkfreigaben für die Datenbank
• Immich: Docker Compose Installation — die beiden Download-Adressen, die Variablen der .env und die Einschränkung beim Datenbankpasswort
• Immich: Quick Start — Port 2283, das erste Konto als Administrator und der Satz zur Eigenverantwortung bei der Sicherung der Dateien
• Immich: Post Installation — Speicher-Template, Bezugsquellen der mobilen Apps und der Verweis auf die 3-2-1-Strategie
• Immich: Backup and Restore — der pg_dump-Befehl im Wortlaut, die kritischen Unterverzeichnisse und die Warnung gegen das Kopieren des Postgres-Datenverzeichnisses
• Immich: Reverse Proxy — Uploadgrenze, Zeitgrenzen von 600 Sekunden und die Kopfzeilen für WebSockets
• Immich: External Libraries — Einbinden mit :ro, Importpfade, Ausschlussmuster, täglicher Suchlauf und Papierkorb nach 30 Tagen
• Immich: FAQ — Abschalten des maschinellen Lernens ganz oder je Modell, Zurücksetzen des Administratorpassworts
• Immich: Command Line Interface — Umfang der offiziellen CLI und die Empfehlung, für Google-Takeout immich-go zu nehmen
• immich-app/immich: docker/docker-compose.yml — die vier Dienste mit Abbildern, Volumes, Port und Abhängigkeiten
• Immich Blog: Release v3.0.0 — Erscheinungsdatum 1. Juli 2026 und die Einordnung der Änderungen mit Bruch
• immich-app/immich: Release v3.2.0 — Erscheinungsdatum 10. September 2026 und der Hinweis zum Zurücksetzen der Gesichtserkennung
• simulot/immich-go — Selbstbeschreibung des Werkzeugs, unterstützte Plattformen und der Hinweis, vorher eine Sicherung anzulegen
• immich-go: Google Takeout — Aufbau des Archivs, Inhalt der JSON-Dateien und die benannten Schwächen des Exports
• immich-go: Examples — die Befehle für from-google-photos und from-folder samt Optionen
• immich-go: Best Practices — API-Schlüssel, Probelauf, Anhalten der Hintergrundaufträge und Wiederaufnahme nach Abbruch
• Google: Daten herunterladen (Datenexport) — Auswahl einzelner Dienste, Dateityp und Archivgrösse, Ablauf nach etwa sieben Tagen und höchstens fünf Downloads

The post Immich selbst hosten: Google Fotos ersetzen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das ist die eigentliche Nachricht. Als wir im August auseinandergenommen haben, warum beim digitalen Euro ein Versprechen kein Protokoll ist, stand am Ende ein Satz: Wenn ihr eine einzige Sache an diesem Projekt verfolgen wollt, dann den Offline-Modus. Er ist der einzige Teil des Entwurfs mit echter Bargeldeigenschaft. Genau dieser Teil wird im Pilot nur in seiner kleinsten Ausbaustufe erprobt. Alles, was an der Ladenkasse passiert, läuft online.

Digitaler Euro Pilot: Händler bewerben sich bis zum 27. Oktober

Der Aufruf an die Händler steht als PDF auf der Dokumentenseite der EZB, zusammen mit einem Bewerbungsfragebogen, einer Unterschriftenerklärung und dem Teilnahmevertrag samt drei Anhängen. Die Fristen sind knapp: eine Informationsveranstaltung am Dienstag, 6. Oktober 2026, Bewerbungsschluss am Dienstag, 27. Oktober 2026 um 17:00 Uhr MEZ.

Bewerben darf sich, wer in der EU niedergelassen ist, Kunden in mindestens zwei der Pilotländer bedient, einen aktiven Online- oder App-Shop betreibt und bereit ist, sowohl mit der EZB als auch mit einem am Pilot beteiligten Acquiring-Dienstleister einen Vertrag zu schliessen. Die Plattform muss flexibel genug sein, um den Beta-Euro einzubinden. Wie viele Händler am Ende genommen werden, legt die EZB nicht fest: Die Zahl hänge von den eingegangenen Bewerbungen ab und davon, was nötig sei, um die Ziele des Pilots abzudecken. Einzelne Branchen werden bevorzugt, andere können ausgeschlossen werden.

Pilotländer sind Belgien, Deutschland, Estland, Finnland, Frankreich, Griechenland, Irland, Italien, Kroatien, Lettland, Litauen, Luxemburg, Niederlande, Österreich, Portugal, Slowakei, Slowenien, Spanien und Zypern — neunzehn Länder, passend zu den neunzehn nationalen Zentralbanken, die laut EZB mittesten.

Bezahlt wird für die Mitarbeit nichts. Im Aufruf steht wörtlich, ausgewählte Händler erhielten keine finanzielle Vergütung über die Zahlungen hinaus, die für die tatsächlich gekauften Waren und Dienstleistungen eingehen. Dafür sollen sie den Beta-Euro einbinden, während der Betriebsphase Live-Transaktionen abwickeln, laufend Rückmeldung geben und über Transaktionsleistung, technische Störungen und Akzeptanzdaten berichten. Die EZB nennt das Freiwilligkeit. Im Handel heisst eine solche Vereinbarung sonst Praktikum.

Wer den digitalen Euro testet — und wer nicht

Auf der Projektseite zum Pilot nennt die EZB die Besetzung: 36 im Euroraum zugelassene Zahlungsdienstleister, ausgewählte Händler sowie Mitarbeiter der EZB und der neunzehn nationalen Zentralbanken, die den Beta-Euro im Alltag ausprobieren sollen — beim Bezahlen in der Kantine etwa oder für andere Dienstleistungen.

Die Öffentlichkeit kommt in dieser Aufzählung nicht vor. Der digitale Euro wird also zunächst von Leuten benutzt, die beruflich an ihn glauben müssen. Das ist für einen technischen Testlauf vertretbar — Lastverhalten, Abstimmungsprozesse und Fehlerbehandlung lassen sich so prüfen. Es heisst aber auch, dass die Fragen, an denen ein Zahlungsmittel im Alltag scheitert, im Pilot gar nicht erst auftauchen: Was passiert bei jemandem ohne Smartphone, ohne Bankkonto, ohne Deutschkenntnisse, mit einer gescheiterten Identitätsprüfung? Die Pilotgruppe besteht aus Zentralbankangestellten. Von denen hat niemand diese Probleme.

Bemerkenswert ist ausserdem, dass der Zahlungsdienstleister-Teil deutlich grösser ausgefallen ist als geplant. Im entsprechenden Aufruf vom 5. März 2026 hatte die EZB zwischen zehn und dreissig Dienstleister gesucht, Bewerbungsschluss war der 14. Mai 2026. Geworden sind es 36. An Interesse aus der Zahlungsbranche mangelt es also nicht.

Vier Anwendungsfälle — und offline ist nur einer davon

Der Aufruf an die Zahlungsdienstleister ist das ergiebigste Dokument des ganzen Vorgangs, weil er den Prüfumfang einzeln auflistet. Vier Anwendungsfälle stehen darin:

• Online zwischen Privatpersonen. Der Zahler überweist an einen anderen Endnutzer und stösst die Zahlung über eine eindeutige Kennung an, einen Alias oder eine DEAN.
• Offline zwischen Privatpersonen über NFC. Der Zahler gibt den Betrag in der Bezahl-App ein, und zwar ausdrücklich, ohne dass eines der beiden Geräte mit dem Internet verbunden sein muss.
• Online an der Ladenkasse über NFC. Bezahlen im Geschäft, technisch über SoftPOS, also ein Händlergerät ohne eigenes Kartenterminal.
• Online im E-Commerce und M-Commerce. Der Zahler überweist an ein Unternehmen als Bezahlung für Waren oder Dienstleistungen auf einer Website oder in einer App.

Der Händleraufruf vom September deckt davon genau einen ab, den vierten: den sogenannten Remote-P2B-Fall, Zahlungen für Waren und Dienstleistungen über Websites und mobile Anwendungen. Wer sich jetzt bewirbt, testet den digitalen Euro also im Online-Shop, nicht an der Theke.

Und der entscheidende Punkt steht in der Aufzählung selbst: Offline kommt genau einmal vor, zwischen zwei Privatpersonen, über NFC. Am Verkaufsort ist jede Zahlung im Pilot eine Online-Zahlung. Dass netzpolitik.org das bereits am 4. August 2026 berichtet hat, lässt sich mit dem Aufruf vom März im Wortlaut bestätigen.

Warum ausgerechnet diese Lücke zählt

Der Offline-Modus ist der einzige Teil des digitalen Euro, bei dem kein zentraler Datensatz entsteht. Der Wert liegt lokal auf einem Gerät, die Übertragung braucht kein Netz, und die Transaktionsdaten kennen nur die beiden Beteiligten. Deshalb gilt dort auch die Bargeldregel: Wer das Gerät verliert, verliert das Geld. Alles, was am digitalen Euro einem Geldschein ähnelt, hängt an diesem Modus.

Die offenen Fragen dazu sind seit Monaten dieselben. Wie hoch darf der Offline-Betrag sein? Wie viele Zahlungen sind hintereinander ohne Netzkontakt möglich, bevor ein Abgleich erzwungen wird? Ist das Speichermedium herstellerunabhängig, und ist seine Firmware offengelegt? Keine dieser Fragen beantwortet ein Pilot, der offline nur zwischen zwei Privatpersonen prüft. Der Alltagsfall — im Laden stehen, kein Netz haben, trotzdem bezahlen können — ist im Prüfplan schlicht nicht vorgesehen.

Das lässt sich nüchtern erklären: SoftPOS ohne Netz ist technisch anspruchsvoll, und ein Pilot muss Prioritäten setzen. Das stimmt. Es bleibt trotzdem der Befund, dass von zwölf Monaten Testbetrieb kein einziger Tag darauf verwendet wird, die einzige bargeldähnliche Eigenschaft des Systems dort zu erproben, wo Bargeld heute tatsächlich benutzt wird. Wer 2028 die Auswertung liest, wird über den Kassenfall nichts darin finden.

Der Zeitplan steht, das Gesetz noch nicht

Die EZB selbst formuliert die Abhängigkeit sauber. Sie wolle für eine mögliche erste Ausgabe des digitalen Euro im Jahr 2029 bereit sein — unter der Annahme, dass die Verordnung 2026 verabschiedet wird. Und weiter: Ob ein digitaler Euro ausgegeben wird, entscheide die EZB erst, wenn die Verordnung verabschiedet ist.

Verabschiedet ist sie nicht. Das Europäische Parlament hat am 9. Juli 2026 mit 416 zu 169 Stimmen bei 22 Enthaltungen beschlossen, Verhandlungen mit dem Rat aufzunehmen; das war das Mandat, nicht das Gesetz. Seither läuft der Trilog. Der Brüsseler Dienst Agence Europe berichtete am 8. September 2026 von der zweiten politischen Verhandlungsrunde und nannte als Themen unter anderem die Einführungsphase samt Pilottests sowie Artikel 23 zu Online- und Offline-Zahlungen. Verhandelt wird also gerade das, was im Pilot schon festgelegt ist.

Das ist kein Skandal, sondern Projektlogik: Wer 2029 liefern will, kann nicht bis zur Unterschrift warten. Es verschiebt aber Gewicht. Eine Infrastruktur, die drei Jahre vor dem Rechtsrahmen gebaut und erprobt wird, setzt Fakten, an denen sich der Rechtsrahmen anschliessend orientiert. Denselben Mechanismus haben wir bei der Schweizer E-ID beschrieben, wo die technische Wahl längst getroffen war, bevor über sie gestritten wurde.

Haltegrenze und Gebühren bleiben ungeklärt

Zwei Streitpunkte hat auch dieser Vorgang nicht bewegt. Der erste ist die Haltegrenze, also die Zahl, die festlegt, wie viele digitale Euro ihr überhaupt halten dürft. Sie ist bis heute nirgends beziffert; auf der Dokumentenseite der EZB, die jedes Papier mit Datum auflistet, taucht keine Zahl auf. Strittig ist nicht einmal die Höhe, sondern wer sie festsetzt: Nach der Analyse der Kanzlei Freshfields vom 15. Juli 2026 will das Parlament einen delegierten Rechtsakt der Kommission auf Empfehlung der EZB, der Rat dagegen einen Durchführungsbeschluss des Rates mit verstärkter qualifizierter Mehrheit. Welche Variante gewinnt, entscheidet darüber, wie leicht sich diese Zahl später ändern lässt — und genau das macht sie zu einem Steuerungsinstrument, wie wir es bei der Spar- und Investitionsunion beschrieben haben.

Der zweite Streitpunkt betrifft die Händler direkt: die Gebühren. Das Fachmagazin etailment berichtete am 21. September 2026, dass Parlament und Rat in der Übergangsphase unterschiedliche Modelle für die Deckelung der Händlergebühren verfolgen und der Verband Ecommerce Europe eine vereinfachte Gebührenberechnung verlangt. Die Position des Verbands ist nachvollziehbar: Ein Zahlungsmittel, das für den Händler teurer ist als die Karte, setzt sich nicht durch — es sei denn, er muss es ohnehin annehmen. Und genau das ist beim digitalen Euro vorgesehen, mit Ausnahmen für Kleinst- und Kleinunternehmen ohne digitale Zahlungsmöglichkeit. Dass Regulierung über Vermittler wirkt statt über Verbote, ist auf diesem Blog kein neues Thema; beim Auslandskonto nach CRD VI lief es genauso.

Wie es weitergeht

Für euch gibt es hier nichts zu installieren und nichts anzumelden. Es gibt aber vier Termine, an denen sich ablesen lässt, wohin das Projekt läuft.

• 6. Oktober 2026: Informationsveranstaltung der EZB für interessierte Händler. Interessant wird, ob dabei Unterlagen öffentlich werden, die über den Aufruf hinausgehen.
• 27. Oktober 2026, 17:00 Uhr: Bewerbungsschluss. Ob die EZB danach nennt, wie viele Händler sich beworben haben, ist die erste belastbare Kennzahl zur Akzeptanz im Handel.
• Ende 2026: Zieltermin der Gesetzgeber für den Abschluss des Trilogs. Die beiden Punkte, auf die es dabei ankommt, sind Artikel 23 zu Online- und Offline-Zahlungen und die Zuständigkeit für die Haltegrenze.
• Zweite Jahreshälfte 2027: Start des zwölfmonatigen Testbetriebs. Wenn bis dahin kein Anwendungsfall für Offline-Zahlungen an der Kasse nachgereicht wird, ist die Frage für diese Projektphase erledigt.

Fazit: Ein Testlauf, der die Streitfragen umgeht

Der Pilot ist gut gebaut für das, was er prüfen soll. Er prüft, ob die Infrastruktur trägt: ob Zahlungen ankommen, ob die Abstimmung zwischen Zentralbank, Dienstleister und Händler funktioniert, ob eine Plattform den Beta-Euro einbinden kann. Das sind reale Fragen, und sie brauchen einen Testlauf.

Nur sind es nicht die Fragen, an denen sich die öffentliche Debatte entzündet. Die drehte sich um Bargeldeigenschaften, um Haltegrenzen, um die Frage, was ohne Netz und ohne Konto noch geht. Der Prüfplan enthält davon: Offline zwischen zwei Privatpersonen, sonst nichts. Getestet wird die Technik, nicht das Versprechen.

Das sollte niemanden überraschen. Ein Pilot beantwortet die Fragen, die seine Auftraggeber gestellt haben, und die EZB hat nie behauptet, etwas anderes zu tun. Die Arbeitsteilung ist nur bemerkenswert sauber: Die technischen Fragen bekommen zwölf Monate Praxis mit 36 Dienstleistern in neunzehn Ländern, die politischen bekommen einen Trilog. Wer wissen will, wie der digitale Euro am Ende aussieht, sollte deshalb weniger auf die Pilotberichte schauen als auf Artikel 23 — und darauf, wer künftig die Haltegrenze festsetzen darf.

Quellen und weiterführende Links

• EZB: Call for expression of interest — Participation of merchants in the digital euro pilot, 15.09.2026 (PDF)
• EZB: Call for expression of interest für Zahlungsdienstleister, 05.03.2026 (PDF) — enthält die vier Anwendungsfälle
• EZB: Projektseite zum Pilotbetrieb des digitalen Euro
• EZB, MIP News: Call for payment service providers to participate in digital euro pilot now open, 05.03.2026
• EZB: Technical documents and research — alle Dokumente zum digitalen Euro mit Datum
• Banca d'Italia: The European Parliament decided to open negotiations on the Digital Euro Regulation, 09.07.2026
• Agence Europe: EU co-legislators seek first political compromises on digital euro, 08.09.2026
• Freshfields: Europe's digital euro heads to last stage of negotiations, 15.07.2026
• netzpolitik.org zum Testbetrieb des digitalen Euro und zur Zusammensetzung der Testgruppe, 04.08.2026
• etailment: Gebührenstreit offen, Pilotversuch 2027 — der digitale Euro rückt näher, 21.09.2026

Stand: 21. September 2026. Die Verordnung zum digitalen Euro ist nicht verabschiedet; alle Angaben zum Zeitplan stehen unter diesem Vorbehalt.

The post Digitaler Euro Pilot: online ja, an der Kasse nein appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wir haben im April an dieser Stelle beschrieben, wie weltweit Altersverifikation bis auf die Betriebssystemebene wandert, und damals festgestellt, dass es in der EU noch kein Gesetz gibt, das eine flächendeckende Alterskontrolle vorschreibt. Kurz darauf hielt die EU-Altersverifikations-App zwei Minuten. Jetzt gibt es das Gesetz. Die Argumente von damals — Kinder umgehen Sperren, Ausweisdaten werden geleakt, Eltern werden entmündigt — gelten weiter und werden hier nicht wiederholt. Dieser Kommentar schaut auf etwas anderes: auf die Frage, wen der KIDS Act prüft und wen nicht. Die Antwort ist unbequemer als jedes Leak-Szenario.

EU KIDS Act: was die Kommission am 17. September vorgelegt hat

Der Name ist ein Akronym, das sich jemand in Brüssel sehr lange überlegt haben muss: "EU Keeping Internet Digital Spaces Accountable and Trustworthy". Der Verordnungsvorschlag kommt mit einer Mitteilung zum EU-Ansatz für Kinderschutz im Netz und einer Folgenabschätzung. Als Verordnung würde er in allen Mitgliedstaaten unmittelbar gelten, ohne nationale Umsetzung. Laut der Analyse der Kanzlei Reed Smith verbietet er den Mitgliedstaaten sogar ausdrücklich, strengere Mindestalter festzulegen.

Die Alterstreppe: 13, 15 und eine Stunde am Tag

Kommissionspräsidentin von der Leyen hat die Grundregel in ihrer Erklärung auf eine Zeile gebracht: "no social media under the age of 13; no personal account under the age of 15". Dazwischen liegt eine Stufe, die es so bisher nirgends gab. Wer 13 oder 14 ist, bekommt kein eigenes Konto, sondern ein von den Eltern verwaltetes Mini-Konto mit eingeschränkten Funktionen und höchstens einer Stunde Nutzung pro Tag. Kontakte müssen vorab freigegeben werden. Ab 15 ist ein eigenes Konto erlaubt, die Schutzpflichten für Minderjährige gelten aber bis 18 weiter.

Für diese Mini-Konten müssen Eltern nicht nur das Alter des Kindes nachweisen, sondern auch, dass sie überhaupt sorgeberechtigt sind. Die FAQ der Kommission verlangen dafür von jedem Mitgliedstaat "a free, privacy-preserving way to prove parental responsibility". Ein solches Dokument gibt es heute in keinem Mitgliedstaat. netzpolitik.org hat im geleakten Entwurf nachgelesen, wie die Kommission die Lücke überbrücken will: zuerst mit einer Selbstauskunft der Eltern, später mit Abfragen in nationalen Registern und mit Sorgerechtsbescheinigungen, die erst noch geschaffen werden müssen.

Beweislastumkehr und sechs Prozent

Der zweite Pfeiler ist aus Sicht der Kommission der wichtigere. "Now they have to prove to us that they are safe", heisst es in der Erklärung. Sehr grosse Plattformen mit mehr als 45 Millionen Nutzern in der EU müssen vorab einen Plan einreichen, wie sie Minderjährige schützen, von unabhängigen Prüfern bestätigt und auf eigene Kosten. Endloses Scrollen, Benachrichtigungen zur Schlafenszeit, Belohnungen für Serien und Dauerposten werden für Minderjährige untersagt, Empfehlungssysteme sollen für sie auf Sicherheit statt auf Verweildauer optimiert werden. Bei Verstössen drohen laut FAQ Bussen von bis zu sechs Prozent des weltweiten Jahresumsatzes. Die Aufsicht baut auf den Strukturen des Digital Services Act auf, den wir an anderer Stelle bereits als möglichen Zensurmechanismus beschrieben haben.

Bis hierhin ist das ein Gesetz, über das sich streiten lässt, aber nicht zwingend eines, über das sich aufregen muss, wer 40 ist und kein TikTok hat. Die Aufregung beginnt bei der Frage, wie eine Plattform überhaupt weiss, wer 13, 15 oder 40 ist.

Der Satz, um den es geht: "most adults will notice nothing"

Selbstauskunft genügt nicht mehr, das stellt die Kommission ausdrücklich klar. Das Alter muss über zertifizierte Lösungen nachgewiesen werden, die von den Plattformen unabhängig sind — "including a free EU age verification app and, in time, the European Digital Identity Wallet". Die Plattform prüft laut FAQ keine Ausweise und erfährt nicht, wer ihr seid. So weit das Versprechen.

Dann folgt die Frage, die sich alle Erwachsenen stellen: Muss ich jetzt auch mein Alter nachweisen? Die Antwort der Kommission im Wortlaut: "When providers already have an estimation of the user's age based on multiple signals such as account creation date or credit card details, there will be no age verification required for most existing users." Und an anderer Stelle, noch deutlicher: "Where a platform can already tell with high confidence that a user is an adult, no new check is needed, so most adults will notice nothing."

Das ist als Beruhigung gemeint. Lest es trotzdem zweimal. Wer nicht geprüft wird, ist nicht der datensparsame Nutzer, sondern der, über den die Plattform schon genug weiss: ein Konto seit 2012, eine hinterlegte Kreditkarte, dazu die "multiple signals", die nirgends abschliessend aufgezählt werden. Wer der Plattform dagegen wenig verrät — ein junges Konto, keine Zahlungsdaten, kein Klarname, vielleicht bewusst so eingerichtet —, liefert keine Grundlage für eine Schätzung. Für ihn bleibt nur der Nachweis.

Der KIDS Act verteilt die Last der Alterskontrolle damit nicht nach Alter, sondern nach Bekanntheitsgrad. Das Gesetz erklärt die Schätzung, die eine Plattform aus ihren eigenen Daten zieht, zum Freifahrtschein. Die Plattform, die euch am besten ausgeleuchtet hat, erspart euch den Ausweis. Das ist, nüchtern betrachtet, ein Rabatt auf Überwachung.

Die Kommission würde einwenden, dass die Schätzung nur für Bestandskonten gilt und nicht für neue. Das stimmt, macht es aber nicht besser. Wer neu anfängt — ein Konto für ein Projekt, ein zweites Konto, ein Konto nach einem Datenleck, ein Konto von jemandem, der sich bisher ferngehalten hat —, muss sich ausweisen. Wer seit zehn Jahren alles preisgibt, nicht. Anonymität wird damit nicht verboten. Sie wird zu dem Zustand, der sich rechtfertigen muss.

Vom Leak zum Vorschlag: aus "alle" wurde "die meisten"

Wie bewusst dieser Weg gewählt ist, zeigt der Vergleich mit dem Entwurf, den netzpolitik.org zwei Tage vor der Vorstellung in Eckpunkten und einen Tag davor im Detail veröffentlicht hat. Dort stand nach der Auswertung der Redaktion noch, dass auch alle Erwachsenen eine Alterskontrolle durchlaufen müssen, ohne pauschale Ausnahme. Im veröffentlichten Material der Kommission sind es nun "most existing users", die nichts bemerken sollen.

Das lässt sich als Entschärfung lesen, und politisch ist es genau das: Ein Gesetz, das sämtliche Erwachsenen der EU an die Ausweiskontrolle schickt, übersteht keinen Wahlkampf. Aber die Entschärfung ist nicht neutral. Sie nimmt die Zumutung bei denen weg, die ohnehin gläsern sind, und lässt sie bei denen, die es nicht sein wollen. Der Leak war ehrlicher. Er hat alle gleich behandelt, schlecht zwar, aber gleich.

Ob die Formulierung im Verordnungstext selbst so steht wie in den FAQ, konnten wir nicht prüfen: Das PDF des Vorschlags ist über die Seite der Kommission verlinkt, liess sich aus unserer Umgebung aber nicht abrufen. Die FAQ sind allerdings die offizielle Erklärung der Kommission zu ihrem eigenen Vorschlag. Wenn der Text strenger wäre als die FAQ, hätte die Kommission ein anderes Problem.

Zero Knowledge als Gesetzesbegriff

Der zweite Satz, der Beruhigung verspricht, lautet: "The law requires 'zero knowledge proof' technology that cannot identify, locate, track or profile anyone." Das klingt nach dem Stand der Kryptographie. Es lohnt sich, nachzusehen, was dahintersteht.

Die Organisation European Digital Rights hat zehn Tage vor der Vorstellung eine Analyse der EU-Altersverifikations-App veröffentlicht. Darin steht, dass die Vorgaben für die sogenannte Mini-Wallet Zero-Knowledge-Beweise nur mit "SHOULD" verlangen, nicht mit "SHALL", und dass die Kommission die Anforderung an Unverknüpfbarkeit von "ensuring" auf "hindering" heruntergestuft habe. Die stattdessen verwendete Batch Issuance, also ein Stapel Einmalnachweise, mache Verfolgung schwerer: "it does not make tracking impossible". Selbst mit echtem Zero Knowledge, so EDRi, lasse sich eine Verknüpfung über das Backend der App, die Netzwerkebene oder den zeitlichen Zusammenhang von Ausstellung und Vorweisung herstellen.

Das Problem mit dem Stapel Einmalnachweise haben wir beim E-ID-Kommentar ausführlich beschrieben, einschliesslich der Feststellung in der technischen Spezifikation der EUDI-Wallet, dass derzeit kein Zero-Knowledge-Verfahren reif genug für den Einsatz ist. Neu ist hier etwas anderes: Ein Verfahren, das die eigene Referenzimplementierung nur als Empfehlung führt, wird in der Kommunikation zum Gesetz zur Pflicht erklärt. netzpolitik.org ist im Entwurf auf den Satz "Any age assurance measure shall be zero knowledge proof" gestossen und hat trocken angemerkt, dass eine Massnahme kein Beweis sein kann. Wer den Begriff so verwendet, hat ihn als Etikett gekauft, nicht als Bauplan.

Das ist keine Wortklauberei. Ein Gesetz, das "zero knowledge" verlangt, ohne festzulegen, was genau nicht gewusst werden darf und von wem, lässt sich mit fast jeder Implementierung erfüllen, solange irgendwo ein Beweis im kryptographischen Sinn vorkommt. Die Aufsicht prüft dann, ob das Etikett klebt. Und die Nutzer, die ohnehin nicht geprüft werden, weil die Plattform sie kennt, bemerken davon ohnehin nichts.

App-Stores müssen die EU-App mitliefern — und F-Droid?

Für diesen Blog ist ein Absatz der FAQ besonders interessant, weil er in keiner Pressemitteilung vorkommt: "App stores must age-rate every app, including videogames, with a published methodology, they must not let children access or buy apps inappropriate for their age, and must carry the EU age verification app."

Laut der Auswertung des Entwurfs durch netzpolitik.org fallen darunter nicht nur der App Store und Google Play, sondern ausdrücklich auch Anbieter wie F-Droid. Der Entwurf nimmt zwar Plattformen für die Entwicklung von Open-Source-Software aus, also Orte wie Git-Forges, aber eben nicht Stores, die freie Software verteilen. Zwei Kanzleianalysen, von Reed Smith und Osborne Clarke, zählen ausserdem Betriebssysteme zum Anwendungsbereich; in den FAQ der Kommission tauchen sie nicht auf.

Stellt euch diese Pflichten für ein Freiwilligenprojekt vor: jede App nach einer veröffentlichten Methodik altersklassifizieren, Minderjährige an altersungeeigneten Apps hindern — was voraussetzt, dass der Store weiss, wer minderjährig ist —, und die EU-App zur Altersverifikation ausliefern. F-Droid hat keine Konten, keine Nutzerdaten und kein Interesse daran, beides einzuführen. Genau das ist sein Zweck.

Wer diesen Blog liest, kennt das Muster. Google verlangt seit diesem Jahr, dass Entwickler sich registrieren, bevor ihre Apps auf zertifizierten Geräten installiert werden dürfen, und F-Droid hat öffentlich gewarnt, dass das seine Existenz bedroht. Der KIDS Act setzt nun von der anderen Seite an: nicht bei den Entwicklern, sondern beim Store. Das eine ist eine Konzernentscheidung, das andere ein Gesetz — das Ergebnis für alternative Verteilwege ist dasselbe. Wer nicht registriert, klassifiziert und verifiziert, gilt als Risiko.

Was an der Gegenseite stimmt

Ein Kommentar, der nur die Schwächen eines Gesetzes aufzählt, macht es sich zu leicht. Drei Argumente der Befürworter verdienen eine ernsthafte Antwort.

Erstens: Die Plattformen haben es jahrelang selbst in der Hand gehabt und nichts getan. Das stimmt. Die Beweislastumkehr ist der beste Teil dieses Gesetzes, und die Verbote für endloses Scrollen, nächtliche Benachrichtigungen und Belohnungen für Dauerposten gehen in die Richtung, die auch Kritiker seit Jahren fordern. Die Digitale Gesellschaft in der Schweiz hat im Mai in ihrer Position zu Alterskontrollen genau das verlangt: Empfehlungssysteme regulieren, manipulative Muster abschaffen, keine Push-Nachrichten in der Nacht. Nur braucht keine dieser Massnahmen eine Alterskontrolle. Ein Feed, der für 14-Jährige schädlich ist, wird mit 15 nicht gesund; Simeon de Brouwer von EDRi hat genau das gegenüber netzpolitik.org festgehalten.

Zweitens: Die Plattform sieht keinen Ausweis, nur ein Ja oder Nein. Auch das stimmt, soweit es die Plattform betrifft. Es verschiebt die Frage aber nur um eine Station. Wer die Nachweise ausstellt, wer die App betreibt und was auf der Netzwerkebene sichtbar bleibt, ist genau der Punkt, an dem EDRi ansetzt. Und für die Mehrheit der Erwachsenen spielt der Nachweis ohnehin keine Rolle, weil ihre Plattform sie schätzt, statt zu fragen — mit Daten, die sie ohne jedes Zero Knowledge gesammelt hat.

Drittens: Eine EU-weite Regel ist besser als 27 nationale. Das ist das stärkste Argument, und es ist nicht falsch. Frankreich, Spanien, Griechenland und andere hatten, wie im April beschrieben, eigene Verbote angekündigt, jedes mit eigener Technik. Harmonisierung verhindert einen Flickenteppich. Aber sie verhindert auch jede Abweichung nach oben wie nach unten: Wenn Reed Smith recht hat, darf kein Mitgliedstaat strenger sein — und damit auch keiner einen datensparsameren Weg ausprobieren. Ein einheitlicher Fehler ist nicht besser als 27 verschiedene. Er ist nur schwerer zu korrigieren.

Chris Köver hat den Vorschlag auf netzpolitik.org als Gesetz kommentiert, das es für Eltern "nicht besser, sondern schlimmer" macht, und festgestellt: "In der Praxis lösen diese Pläne keines der Probleme". Dem ist aus Sicht dieses Blogs nur eines hinzuzufügen: Sie schaffen ein neues. Sie machen den Datenbestand der Plattformen zur Eintrittskarte.

Wer übrigens glaubt, das sei ein europäisches Sonderproblem: Im US-Kongress liegt ein Paket mit demselben Namen, der KIDS Act H.R. 7757. Die EFF kritisiert dort, dass Pflichten immer dann greifen, wenn ein Dienst weiss "or should have known", dass jemand minderjährig ist. Auf beiden Seiten des Atlantiks läuft es auf dasselbe hinaus: Die Plattform soll über euer Alter Bescheid wissen. Den Namen haben sich die beiden Gesetzgeber offenbar nicht abgesprochen, die Richtung schon.

Und die Schweiz?

Die Schweiz ist nicht Mitglied der EU, der KIDS Act gilt hier nicht. Die Europarechtlerin Helen Keller sagte gegenüber 20 Minuten trotzdem, es könnte "schon aus Gründen der Praktikabilität für die Schweiz das Einfachste sein, sich der neuen Regelung anzuschliessen". Der Bundesrat prüft seit einem Postulat, das der Ständerat im März 2025 überwiesen hat, ein Social-Media-Verbot für unter 16-Jährige; ein Bericht soll laut Keystone-SDA im nächsten Jahr kommen, und die Forderungen sollen auch in die geplante Plattformregulierung einfliessen.

Der Druck kommt also von zwei Seiten: von der Politik, die nachziehen will, und von den Plattformen, die Funktionen im Zweifel europaweit umbauen, statt für die Schweiz eine Ausnahme zu pflegen. Wie schwerfällig die Schweiz gegenüber Plattformen reguliert, haben wir beim Digital Markets Act beschrieben. Hier wäre Langsamkeit ausnahmsweise ein Vorteil.

Was noch offen ist

Der Vorschlag geht jetzt an Parlament und Rat. Vieles, was über seine Wirkung entscheidet, ist noch nicht festgelegt oder für uns nicht prüfbar:

• Der Verordnungstext selbst. Das PDF liess sich aus unserer Umgebung nicht abrufen. Die Aussagen zu Bestandskonten stammen aus den FAQ der Kommission, die zum Leak aus der Auswertung von netzpolitik.org. Ob die Ausnahme für Erwachsene mit bekanntem Alter im Artikeltext genauso weit reicht, ist offen.
• Was ein "Signal" ist. Kontoalter und Kreditkarte sind Beispiele. Ob Plattformen auch Verhaltensanalysen, Gesichtsschätzungen aus Profilbildern oder Kontaktnetze nutzen dürfen, um ein Alter "with high confidence" festzustellen, sagen die FAQ nicht.
• Der Geltungsbeginn. Bekannt ist nur, dass bestehende Konten innerhalb von sechs Monaten nach Anwendbarkeit geprüft werden müssen. Ab wann die Regeln anwendbar sind, nennt keine der abrufbaren Quellen.
• F-Droid und freie Stores. Ob nicht kommerzielle Stores unter die Pflichten für App-Stores fallen oder unter eine Ausnahme, ist nach den öffentlichen Unterlagen nicht eindeutig. Eine Stellungnahme von F-Droid war am 19. September nicht auffindbar.
• Der Nachweis ohne digitale Identität. Jeder Mitgliedstaat soll mindestens einen kostenlosen Weg anbieten, das Alter nachzuweisen, "including for people without digital ID". Wie dieser Weg aussieht und ob er ohne Smartphone funktioniert, ist nicht beschrieben.
• Die Sorgerechtsbescheinigung. Das Dokument, das Eltern für ein Mini-Konto brauchen, gibt es noch nicht. Wer es ausstellt und welche Daten es enthält, entscheidet darüber, ob aus dem Kinderschutz ein Familienregister wird.

Fazit: Der KIDS Act macht Anonymität zur Ausnahme mit Begründungspflicht

Der EU KIDS Act ist kein Gesetz, das alle Erwachsenen zur Ausweiskontrolle schickt. Das wäre einfacher zu kritisieren. Er ist ein Gesetz, das die Erwachsenen durchwinkt, die ihre Plattform ohnehin kennt, und die übrigen prüft. Die Beweislastumkehr für Plattformen ist richtig, die Designverbote sind überfällig. Aber die Alterskontrolle, die daneben entsteht, belohnt genau das Verhalten, vor dem dieser Blog seit Jahren warnt: ein Konto, einen Namen, eine Kreditkarte, alles an einem Ort.

Der Satz "most adults will notice nothing" ist dafür die ehrlichste Beschreibung. Er stimmt. Wer seit Jahren alles preisgibt, merkt nichts. Wer das nicht getan hat, wird es merken. Ein Gesetz, das Kinder schützen soll und dabei Anonymität zum Sonderfall macht, hat seinen Zweck um eine Generation verfehlt — nämlich um die, die jetzt lernt, dass ein Konto ohne Kreditkarte verdächtig ist.

Quellen und weiterführende Links

• EU-Kommission: Proposal for EU KIDS Act, 17.09.2026
• EU-Kommission: The KIDS Act explained (FAQ)
• EU-Kommission: EU KIDS Act to restrict social media platforms’ access to children in the EU
• EU-Kommission: Statement by President von der Leyen with Executive Vice-President Virkkunen on the EU KIDS Act
• netzpolitik.org: Eckpunkte geleakt, 15.09.2026
• netzpolitik.org: EU-Kommission will Netz mit Alterskontrollen zupflastern, 16.09.2026
• netzpolitik.org: Dieses Gesetz macht es für Eltern nicht besser, sondern schlimmer (Kommentar), 17.09.2026
• EDRi: Why the EU age-verification tool does not solve privacy concerns, 07.09.2026
• Reed Smith: The EU KIDS Act has landed
• Osborne Clarke: EU KIDS Act – Commission announces new restrictions
• Digitale Gesellschaft: Macht Plattformen besser, statt exklusiv!, 27.05.2026
• swissinfo.ch / Keystone-SDA: Verbot von sozialen Medien wird auch in der Schweiz diskutiert, 23.07.2026
• 20 Minuten: EU Kids Act – was das für Schweizer Teenager bedeutet, 16.09.2026
• EFF: The KIDS Act Would Require Age Checks To Get Online (USA)

The post EU KIDS Act: Anonym ist jetzt die Ausnahme appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorausgesetzt wird, dass Flatpak eingerichtet ist und das Flathub-Repository eingebunden. Falls nicht: Der Weg dorthin steht bei uns im Beitrag darüber, wie ihr Snap vom System entfernt und durch Flatpak ersetzt. Wer bei den Paketformaten überhaupt noch schwankt, findet in der Übersicht zu Programminstallationen unter Linux die Einordnung.

Flatpak-Berechtigungen: was eine App ab Werk darf

Die offizielle Dokumentation ist an dieser Stelle erfreulich unmissverständlich. Eine Anwendung im Sandkasten hat laut Sandbox Permissions "extremely limited access to the host environment". Im Einzelnen heisst das: kein Zugriff auf Dateien des Wirtssystems ausser der Laufzeitumgebung, der App selbst, ~/.var/app/$FLATPAK_ID und $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Kein Netzzugriff. Kein Zugriff auf Gerätedateien, abgesehen von /dev/null und ähnlichem. Kein Zugriff auf Prozesse ausserhalb des Sandkastens. Eingeschränkte Systemaufrufe, eingeschränkter Zugriff auf den Sitzungsbus von D-Bus. Und kein Zugriff auf Dienste des Wirtssystems wie X11, den Systembus oder PulseAudio.

Das ist eine Ausgangslage, mit der sich arbeiten lässt. Technisch steckt dahinter kein Flatpak-Eigenbau, sondern bubblewrap, ein Werkzeug, das unprivilegierten Nutzern erlaubt, Container aufzuspannen — mit Namensräumen, Bind-Mounts und Seccomp-Regeln, also mit Kernelmitteln, die es ohnehin gibt.

Der Haken liegt nicht im Sandkasten, sondern in der Liste der Ausnahmen. Jede App bringt im Manifest eine Reihe von Rechten mit, die sie beim Bauen angefordert hat, und die werden beim Start wortlos gewährt. Ein Bildbetrachter mit --filesystem=home sieht euer gesamtes Heimatverzeichnis, inklusive SSH-Schlüssel, Steuerunterlagen und der Wallet-Datei. Niemand fragt euch beim ersten Start, ob das in Ordnung ist. Genau hier setzen die Werkzeuge an, um die es im Folgenden geht.

Warum das mit chmod und chown nichts zu tun hat

Eine Verwechslung vorweg, weil sie die häufigste ist. Die klassischen Unix-Rechte regeln, wer auf eine Datei zugreifen darf — welcher Benutzer, welche Gruppe. Wie das funktioniert, haben wir im Beitrag zu Linux-Gruppen und Berechtigungen mit rwx, chmod und chown ausführlich behandelt. Diese Schicht sagt aber nichts darüber aus, was ein Programm tut, das ihr selbst gestartet habt. Für den Kernel seid ihr das, und ihr dürft eure eigenen Dateien lesen.

Die Sandbox ist die Schicht darüber. Sie schränkt ein, was ein Prozess mit euren Rechten tatsächlich erreichen kann. Ein verwandter Ansatz ist Mandatory Access Control, wie wir sie beim Absichern des Firefox mit AppArmor gezeigt haben — nur dass dort ein Profil von aussen aufgesetzt wird, während Flatpak den Sandkasten mitbringt und ihr nur die Türen darin verriegelt. Beides schliesst sich nicht aus, beides ersetzt sich aber auch nicht.

Die sechs Stellschrauben der Sandbox

Alles, was aus dem Sandkasten herausführt, fällt in eine von sechs Kategorien. Die Namen dieser Kategorien sind zugleich die Schalter, mit denen ihr sie bedient — auf der Kommandozeile wie in Flatseal.

Zu jedem dieser Schalter gibt es die Gegenform: --unshare, --nosocket, --nodevice, --nofilesystem, --no-talk-name und --disallow. Genau die braucht ihr, denn ihr wollt in aller Regel etwas wegnehmen, nicht dazugeben.

Drei Werte, die besondere Aufmerksamkeit verdienen

--filesystem=host bedeutet Zugriff auf alle obersten Pfade von / und deren Unterpfade, abgesehen von wenigen reservierten. --filesystem=home gewährt das Heimatverzeichnis mit Ausnahme von ~/.var/app. Beide lassen sich mit den Zusätzen :ro für nur lesend und :create für lesend und schreibend samt Anlegen des Verzeichnisses verfeinern. Die Dokumentation formuliert die Regel dazu selbst: "As a general rule, static and permanent filesystem access should be limited as much as possible."

--socket=session-bus und --socket=system-bus heben die Filterung des D-Bus vollständig auf. Die Dokumentation nennt das ausdrücklich ein Sicherheitsrisiko: "Access to the entire bus with --socket=system-bus or --socket=session-bus stops the filtering and using them is a security risk." Eine App mit vollem Sitzungsbus kann mit allem sprechen, was auf eurem Desktop lauscht — und das ist mehr, als die meisten vermuten.

--share=network ist nicht nur ein Netzzugang. Die Sandbox Permissions Reference weist darauf hin, dass damit auch der Zugriff auf alle Dienste des Wirtssystems freigeschaltet wird, die über abstrakte Unix-Sockets erreichbar sind — und die kennen keine Rechteprüfung. Betroffen sind unter anderem der X-Server und der Sitzungsbus. Ein Netzrecht ist also potenziell mehr als ein Netzrecht.

Erst nachsehen: welche Rechte hat die App wirklich?

Bevor ihr irgendetwas ändert, schaut ihr nach. Die Anwendungs-ID bekommt ihr aus der Liste der installierten Pakete:

flatpak list --app --columns=name,application,origin

Die zweite Spalte ist die Anwendungs-ID in der Form org.mozilla.firefox oder org.gimp.GIMP. Mit ihr fragt ihr die Rechte ab:

flatpak info --show-permissions org.mozilla.firefox

Die Kurzform ist -M. Die Ausgabe ist eine Abschnittsdatei im INI-Stil mit einer Gruppe [Context], in der die Schlüssel shared, sockets, devices, filesystems und features stehen, dazu je nach App eine Gruppe für die D-Bus-Regeln. Genau diese Schlüssel entsprechen den Schaltern aus der Tabelle oben.

Zwei weitere Abfragen sind im Alltag nützlich. Das vollständige Manifest mit allen Metadaten liefert:

flatpak info --show-metadata org.mozilla.firefox

Und wenn ihr wissen wollt, ob eine bestimmte App an einen bestimmten Pfad herankommt, fragt ihr das direkt ab, statt es zu raten:

flatpak info --file-access=$HOME/.ssh org.mozilla.firefox

Die Handbuchseite flatpak-info(1) beschreibt alle Optionen. Wichtig zu wissen: Sobald ihr eine --show-…-Option oder --file-access benutzt, wechselt die Ausgabe in ein maschinenlesbares Format. Das ist praktisch, wenn ihr die Abfrage in ein Skript giesst.

flatpak override: Rechte auf der Kommandozeile ändern

Das Werkzeug der Wahl ist flatpak-override(1). Die Handbuchseite beschreibt seinen Zweck knapp: "Overrides the application specified runtime requirements. This can be used to grant a sandboxed application more or less resources than it requested." Das Manifest der App bleibt dabei unangetastet — ihr legt eine zusätzliche Schicht darüber.

Benutzerweit oder systemweit

--user ändert eine Einstellung nur für euer Benutzerkonto, --system für die systemweite Installation. Für --system braucht ihr Administratorrechte. Im Zweifel nehmt ihr --user: Die Änderung gilt dort, wo ihr arbeitet, und ein zweites Konto auf demselben Rechner bleibt unberührt.

Ein Recht wegnehmen

Der häufigste Fall. Ihr entzieht einer App den Vollzugriff auf das Heimatverzeichnis:

flatpak override --user --nofilesystem=home org.mozilla.firefox

Ebenso lassen sich Netz, Geräte und Bus-Zugriffe entziehen:

flatpak override --user --unshare=network org.gimp.GIMP
flatpak override --user --nodevice=all org.gimp.GIMP
flatpak override --user --nosocket=session-bus org.gimp.GIMP

Die Handbuchseite beschreibt --nofilesystem genau so: "Undo the effect of a previous --filesystem=FILESYSTEM in the app's manifest or a lower-precedence layer of overrides." Damit ist auch gesagt, dass es mehrere Schichten gibt und dass eine spätere die frühere übersteuert.

Ein Recht gezielt wieder geben

Wenn ihr home weggenommen habt, die App aber einen bestimmten Ordner braucht, gebt ihr genau den zurück — und sonst nichts:

flatpak override --user --filesystem=~/Bilder:ro org.gimp.GIMP
flatpak override --user --filesystem=~/Projekte/grafik:create org.gimp.GIMP

:ro steht für nur lesend, :create für lesend und schreibend samt Anlegen des Verzeichnisses, falls es noch nicht existiert. Ohne Zusatz gilt lesend und schreibend auf ein bestehendes Verzeichnis.

Kontrollieren und zurücksetzen

Was ihr gesetzt habt, zeigt euch --show, und --reset räumt es wieder ab:

flatpak override --user --show org.gimp.GIMP
flatpak override --user --reset org.gimp.GIMP

Das ist die wichtigste Zeile dieses Artikels, denn sie nimmt jedem Experiment den Schrecken: Wer sich verrannt hat, setzt zurück und fängt von vorn an. Am Manifest der App ändert sich dabei nichts.

Globale Overrides für alle Anwendungen

Lasst ihr die Anwendungs-ID weg, gilt die Einstellung für alle Flatpaks. Die Handbuchseite sagt das zu --reset und --show ausdrücklich: ohne APP betreffen sie "the global overrides". Damit lässt sich eine Grundlinie ziehen:

flatpak override --user --nofilesystem=host
flatpak override --user --nosocket=x11

Achtung: Ein globales --nosocket=x11 legt auf einem X11-Desktop sämtliche grafischen Flatpak-Anwendungen still. Setzt das nur, wenn eure Sitzung tatsächlich auf Wayland läuft, und prüft das vorher mit echo $XDG_SESSION_TYPE. Ein globales Override, das alles kaputtmacht, fällt erst beim nächsten Programmstart auf — und dann sucht ihr an der falschen Stelle.

Wo die Overrides liegen und wer wen übersteuert

Overrides sind gewöhnliche Textdateien. Die Handbuchseite nennt für den Benutzermodus den Pfad $XDG_DATA_HOME/flatpak/overrides, auf einem Standardsystem also ~/.local/share/flatpak/overrides/. Je Anwendung liegt dort eine Datei, die genauso heisst wie die Anwendungs-ID; die globalen Einstellungen stehen in einer Datei namens global.

Das Format ist dasselbe wie bei flatpak info --show-metadata, also Abschnitte im INI-Stil mit einer Gruppe [Context]. Ihr könnt diese Dateien mit einem Editor öffnen, versionieren und auf einen anderen Rechner kopieren. Für ein neu aufgesetztes System ist das der schnellste Weg, die eigene Rechtelage wiederherzustellen — ein Ordner, ein cp, fertig.

Die Reihenfolge, in der die Schichten greifen, ist die logische: Zuunterst steht, was die App im Manifest angefordert hat. Darüber legen sich die systemweiten Overrides, darüber die benutzerweiten, und ganz oben stehen die Rechte, die ihr einer App für einen einzelnen Start mit flatpak run und denselben Schaltern mitgebt. Eine höhere Schicht kann eine tiefere sowohl erweitern als auch beschneiden.

Flatseal: dasselbe mit der Maus

Flatseal beschreibt sich selbst als "a graphical utility to review and modify permissions from your Flatpak applications". Es ist von Martin Abente Lahaye, steht unter der GPL Version 3 oder später und liegt auf Flathub unter der Anwendungs-ID com.github.tchx84.Flatseal, zum Zeitpunkt dieses Artikels in Version 2.4.1.

flatpak install flathub com.github.tchx84.Flatseal

Was Flatseal tut, ist genau das, was flatpak override tut — es schreibt dieselben Dateien an derselben Stelle. Der Unterschied ist die Übersicht: Links stehen alle installierten Anwendungen, rechts sämtliche Kategorien als Schalterreihe, und ein Schalter, den ihr umlegt, erscheint sofort als Eintrag in der Override-Datei. Das ist der eigentliche Wert des Werkzeugs: Ihr seht auf einen Blick, was eine App angefordert hat und was ihr davon geändert habt, ohne fünf Abfragen zu tippen.

Drei Punkte zur Bedienung, die im Alltag zählen. Erstens gelten Änderungen erst, wenn die betroffene Anwendung neu gestartet wird — eine laufende Instanz behält ihre Rechte bis zum Ende. Zweitens gibt es je Anwendung eine Schaltfläche zum Zurücksetzen, die dem --reset von oben entspricht. Drittens hat Flatseal einen Eintrag "Alle Anwendungen" ganz oben in der Liste; was ihr dort einstellt, landet in den globalen Overrides und gilt für jedes Flatpak auf dem System.

Wer lieber klickt als tippt, verliert dabei nichts — die erzeugten Dateien sind identisch. Wer beides kann, nimmt Flatseal zum Nachsehen und die Kommandozeile zum Wiederherstellen auf dem nächsten Rechner.

Portals: warum weniger Rechte nicht weniger Funktion heissen

Jetzt kommt der Teil, der den ganzen Aufwand erst sinnvoll macht. Wenn ihr einer Anwendung --filesystem=home entzieht, könnt ihr trotzdem weiterhin Dateien darin öffnen. Zuständig dafür sind die Portals.

Die Dokumentation von xdg-desktop-portal nennt den Zweck so: "The primary goal of portals is to expose common functionality and integration with the desktop without requiring apps to write desktop-specific code, or loosen their sandbox restrictions." Der zweite Halbsatz ist der entscheidende.

Praktisch funktioniert das über den Documents-Portal, dessen Dokumentation den Mechanismus beschreibt: "The document portal allows to make files from the outside world available to sandboxed applications in a controlled way." Wählt ihr im Dateidialog eine Datei aus, wird sie in den Dokumentenspeicher aufgenommen und der Anwendung unter /run/user/$UID/doc/$DOC_ID/dateiname zugänglich gemacht. Dort hängt ein FUSE-Dateisystem, das jeder Anwendung nur die Dateien zeigt, für die sie eine Freigabe hat; die erteilten Rechte — lesen, schreiben, weitergeben, löschen — bilden sich in den POSIX-Modusbits dieses Dateisystems ab.

Der Unterschied zum statischen Recht ist damit klar: Statt einer Pauschalerlaubnis für alles im Heimatverzeichnis bekommt die Anwendung eine Einzelfreigabe für genau die Datei, die ihr ausgewählt habt. Der Dateidialog, den ihr dabei seht, gehört nicht zur Anwendung, sondern zum Desktop. Die Anwendung erfährt erst danach, was ihr ausgesucht habt.

Diese dynamisch vergebenen Rechte landen im Permission Store, einer Datenbank, die von den Portals gepflegt wird. flatpak-permission-show(1) zeigt sie an:

flatpak permissions
flatpak permission-show org.gimp.GIMP
flatpak permission-reset org.gimp.GIMP

flatpak permissions listet den gesamten Bestand, permission-show die einer einzelnen Anwendung und permission-reset setzt sie zurück. Merkt euch die Trennung: override betrifft die statischen Rechte aus dem Manifest, permission-* die dynamischen aus den Portals. Beides sind Berechtigungen, beides sind verschiedene Speicher, und wer an der falschen Stelle sucht, findet nichts.

Drei Zuschnitte, die sich sofort lohnen

Der Bildbetrachter oder Medienspieler

Ein Programm, das lokale Dateien anzeigt, braucht weder Netz noch Sitzungsbus. Es braucht die Grafikausgabe und das Verzeichnis, in dem die Dateien liegen:

flatpak override --user --unshare=network org.videolan.VLC
flatpak override --user --nofilesystem=home org.videolan.VLC
flatpak override --user --filesystem=xdg-videos:ro org.videolan.VLC

Prüft danach mit flatpak info --show-permissions org.videolan.VLC und startet das Programm einmal. Braucht es Netz für Streams, nehmt ihr die erste Zeile mit --reset zurück oder setzt sie mit --share=network wieder.

Die Bildbearbeitung

Bei einem Programm, das Dateien öffnet und speichert, ist der Dateidialog über das Portal die richtige Antwort. Ihr nehmt den Vollzugriff weg und gebt nur den Arbeitsordner zurück:

flatpak override --user --nofilesystem=home org.gimp.GIMP
flatpak override --user --filesystem=~/Projekte:create org.gimp.GIMP
flatpak override --user --unshare=network org.gimp.GIMP

Der Browser

Ein Browser braucht Netz, das steht ausser Frage. Was er nicht braucht, ist Lesezugriff auf alles, was in eurem Heimatverzeichnis liegt. Für Downloads und Uploads reicht ein Verzeichnis, alles Weitere geht über den Dateidialog:

flatpak override --user --nofilesystem=home org.mozilla.firefox
flatpak override --user --filesystem=xdg-download org.mozilla.firefox

Falls die Anwendung danach Zugangsdaten nicht mehr im Schlüsselbund ablegen kann, fehlt ihr die D-Bus-Gegenstelle dafür. Die gebt ihr gezielt zurück, statt den ganzen Bus zu öffnen:

flatpak override --user --talk-name=org.freedesktop.secrets org.mozilla.firefox

Was die Sandbox nicht leistet

Ein paar ehrliche Einschränkungen gehören dazu, sonst wird aus einer Schutzschicht ein Sicherheitsversprechen, das sie nicht halten kann.

Erstens bleibt alles bestehen, was über die Portals hereinkommt. Eine Anwendung, der ihr im Dateidialog eure Steuererklärung gebt, hat die Steuererklärung. Der Sandkasten schützt vor dem pauschalen Zugriff, nicht vor eurer eigenen Auswahl.

Zweitens ist ein Recht, das ihr entzieht, nur so wirksam wie die Alternative, die bleibt. Nehmt ihr einer Anwendung home weg und gebt ihr stattdessen --filesystem=host:ro, habt ihr nichts gewonnen, sondern die Lage verschlimmert. Ein Blick in die Ausgabe von --show-permissions nach jeder Änderung erspart solche Eigentore.

Drittens lebt die Paketbasis von Flathub von den Paketbauern, und die entscheiden, welche Rechte eine App ab Werk anfordert. Die Sandbox ist eine Grenze, keine Prüfinstanz. Sie sagt euch nicht, ob ein Paket vertrauenswürdig ist — sie begrenzt nur den Schaden, wenn es das nicht ist. Das ist kein kleiner Unterschied, aber eben auch nicht derselbe.

Viertens gilt alles Gesagte nur für Flatpak. Ein Programm aus dem Paketmanager der Distribution läuft ohne Sandkasten, und ein AppImage ebenso. Wer eine Anwendung wirklich einsperren will, für die es kein Flatpak gibt, landet wieder bei AppArmor oder einem der klassischen Werkzeuge.

Wenn etwas nicht klappt

Die Anwendung startet nicht mehr. Setzt die Overrides für genau diese Anwendung zurück und nähert euch in kleineren Schritten: flatpak override --user --reset org.beispiel.App. Startet sie danach wieder, lag es an einer eurer Änderungen.

Gar keine grafische Anwendung startet mehr. Dann steht die Ursache mit hoher Wahrscheinlichkeit in den globalen Overrides. Ansehen und zurücksetzen lassen sie sich ohne Anwendungs-ID: flatpak override --user --show und flatpak override --user --reset. Typischer Auslöser ist ein entzogener x11- oder wayland-Socket.

Die Änderung wirkt nicht. Prüft dreierlei: ob die Anwendung neu gestartet wurde, ob ihr --user gesetzt habt, während die App systemweit installiert ist (oder umgekehrt), und ob eine andere Schicht euer Override übersteuert. flatpak info --show-permissions zeigt den tatsächlich wirksamen Stand, flatpak override --show nur eure eigene Schicht. Weichen beide voneinander ab, habt ihr die Antwort.

Der Dateidialog zeigt nichts an oder es öffnet sich keiner. Dann fehlt auf dem System das passende Portal-Backend. Gebraucht werden xdg-desktop-portal und je nach Desktop xdg-desktop-portal-gtk, -kde oder -wlr. Auf schlanken Fenstermanager-Installationen fehlt das oft, und dann scheitert jede Anwendung ohne statisches Dateirecht.

Eine Funktion fehlt, und ihr wisst nicht, welches Recht dahintersteckt. Für D-Bus gibt es dafür ein eigenes Mittel. Die Dokumentation nennt es ausdrücklich: flatpak run --log-session-bus $FLATPAK_ID protokolliert, mit welchen Busnamen die Anwendung sprechen will. Aus dieser Liste ergibt sich, welches --talk-name ihr setzen müsst.

Ihr habt den Überblick verloren, was ihr überhaupt geändert habt. Der Ordner ~/.local/share/flatpak/overrides/ beantwortet das in einem Rutsch. Was dort nicht steht, habt ihr auch nicht gesetzt.

Fazit: Die Sandbox ist nur so eng, wie ihr sie einstellt

Flatpak liefert einen Sandkasten, der in der Voreinstellung tatsächlich streng ist — und ein Manifest, das diese Strenge gleich wieder aufweicht, ohne euch zu fragen. Beides zusammen ergibt ein System, das genau so sicher ist, wie jemand es nachträglich einstellt. Der Aufwand dafür ist überschaubar: eine Abfrage, ein bis zwei Overrides, ein Neustart der Anwendung.

Der wichtigste Schritt ist der erste. Lasst einmal flatpak info --show-permissions über eure installierten Anwendungen laufen und schaut, wer alles home oder host in der Liste stehen hat. Erfahrungsgemäss sind es mehr, als angenehm ist. Alles danach ist Handwerk, und das steht oben.

Und die Portals nehmen dem Ganzen die Härte: Weniger statische Rechte heissen nicht weniger Funktion, sondern nur, dass die Anwendung beim Zugriff durch eine Tür geht, die ihr aufhaltet. Das ist die Art von Sicherheit, die im Alltag überlebt — anders als die, bei der nach zwei Wochen alles wieder aufgedreht wird, weil nichts mehr ging.

Quellen und weiterführende Links

• Flatpak-Dokumentation: Sandbox Permissions — Voreinstellungen des Sandkastens, Dateisystem-, D-Bus- und Geräterechte
• Flatpak-Dokumentation: Sandbox Permissions Reference — Einzelwerte mit Erklärung und Sicherheitshinweisen
• Flatpak-Dokumentation: Under the Hood — bubblewrap, Namensräume und Seccomp
• Flatpak-Dokumentation: Desktop Integration — Portals als Rahmen für den Zugriff nach aussen
• Handbuchseite flatpak-override(1) — sämtliche Schalter im Wortlaut
• Handbuchseite flatpak-info(1) — --show-permissions, --show-metadata, --file-access
• Handbuchseite flatpak(1) — Übersicht aller Unterbefehle
• Handbuchseite flatpak-permission-show(1) — der Permission Store der Portals
• XDG Desktop Portal: For App Developers — Zweck und Aufbau der Portals
• XDG Desktop Portal: Documents — Dokumentenspeicher, FUSE-Einhängepunkt und Rechtebits
• Flatseal auf Flathub — Beschreibung, Version und Installationsweg
• Flatseal: Quelltext und README — Lizenz und Projektbeschreibung
• Linux: wichtige Begriffe in der Übersicht — Einordnung von Flatpak und Snap für Einsteiger

The post Flatpak-Berechtigungen einschränken: Flatseal und Terminal appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Fünf Anpassungen der BLAKE2b Difficulty in elf Tagen

Die Betreiber der Informationsseite blake2bminer.com führen jede Anpassung mit Block, Zeitpunkt und Faktor auf. Sie betreiben dafür eine eigene mitvalidierende Node, und sie legen offen, dass ihnen BLAKE2b-Hardware gehört — das ist mehr Transparenz, als die meisten Fachmedien zum selben Thema aufbringen.

Der Wechsel selbst geschah am 30. August um 06:14 UTC bei Block 961.640. Bemerkenswert ist, wie er abgesichert wurde: Die Aktivierung verlangte laut der Statusseite der Kette eine Zeitungsschlagzeile im Coinbase-Eintrag des Blocks, "8-30 NYPost Deride And Conquer". Das ist dieselbe Geste wie im Genesis-Block von 2009 — nur dass sie hier technisch verhindern soll, dass jemand vorzeitig losrechnet.

Warum die erste Anpassung nach unten ging

Die erste Anpassung am 1. September senkte die Schwierigkeit um 41,3 Prozent. Das wirkt widersinnig, weil die Kette zu diesem Zeitpunkt längst wieder im Minutentakt Blöcke ausspuckte. Die Erklärung steckt im Messfenster: Eine Anpassung betrachtet die vergangenen 2.016 Blöcke, und in diesem Fenster lagen die drei Wochen Stillstand vom August, in denen die Abspaltung mit geerbter Difficulty ganze acht Blöcke zustande brachte. Gemessen wurde also überwiegend Stillstand. Wie dieser Mechanismus grundsätzlich arbeitet, steht in unserem Grundlagenbeitrag Was ist die Mining Difficulty.

Ab der zweiten Anpassung kehrte sich das um. Zwischen dem 1. und dem 2. September entstanden 2.016 Blöcke in rund siebzehn Stunden — vorgesehen sind dafür zwei Wochen. Die Difficulty hätte sich etwa verzwanzigfachen müssen. Sie durfte es nicht.

Der Anschlag bei Faktor vier steht seit 2009 im Code

Bitcoin begrenzt jede Anpassung auf den Faktor vier nach oben und ein Viertel nach unten. Die Stelle dazu steht unverändert in src/pow.cpp, unter dem Kommentar "Limit adjustment step":

if (nActualTimespan < params.nPowTargetTimespan/4)
    nActualTimespan = params.nPowTargetTimespan/4;
if (nActualTimespan > params.nPowTargetTimespan*4)
    nActualTimespan = params.nPowTargetTimespan*4;

Diese Bremse ist kein Versehen, sondern Absicht: Sie soll verhindern, dass ein kurzer Ausreisser bei den Zeitstempeln die Kette in eine Richtung katapultiert, aus der sie nicht mehr herauskommt. Die BLAKE2b-Kette hat vorgeführt, was passiert, wenn eine Kette weit unterhalb ihrer tatsächlichen Rechenleistung startet: Sie braucht vier volle Anpassungen, um den Rückstand aufzuholen, und jede davon dauert so lange, wie 2.016 Blöcke eben dauern.

Erst die fünfte Anpassung am 12. September fiel mit dem Faktor 2,99 unter den Anschlag. Das ist die eigentliche Meldung dieser Woche, und sie klingt unspektakulärer als sie ist: Die Difficulty hat die Hashrate eingeholt. Ab jetzt misst die Kette, was tatsächlich an ihr rechnet, statt hinterherzulaufen.

191-mal schwerer, aber nur rund zehnmal mehr Rechenleistung

An dieser Stelle ist eine Unterscheidung wichtig, die in mehreren Berichten untergeht. Die Difficulty ist um das 191-Fache gestiegen, die Rechenleistung nicht. Die Miner-Seite beziffert die Hashrate der Kette kurz nach der Aktivierung auf rund 3 PH/s und Mitte September auf etwa 31 PH/s — ein Faktor von ungefähr zehn. Der Rest des Anstiegs ist schlicht Aufholjagd: Die Kette startete mit einer Difficulty, die viel zu niedrig war, und die vier Anpassungen am Anschlag haben diesen Abstand abgetragen.

Wer aus der Difficulty-Kurve also einen Ansturm von Minern herausliest, liest eine Korrektur. Verzehnfacht hat sich die Rechenleistung trotzdem, und das ist für eine drei Wochen alte Kette beachtlich.

31 PH/s gegen 910 EH/s

Beachtlich heisst nicht sicher. Der Dienst CoinWarz schätzt die Hashrate des SHA-256d-Netzwerks am 14. September auf 910 EH/s. Das sind 910.000 PH/s. Die BLAKE2b-Kette bringt es auf etwa ein Dreissigtausendstel davon.

Diese Zahl ist deshalb entscheidend, weil sie den Preis eines Angriffs bestimmt. Wer die Mehrheit der Rechenleistung auf einer Kette stellt, kann Transaktionen zurückdrehen. Auf der Hauptkette kostet das den Aufbau einer Industrie; auf der BLAKE2b-Kette kostet es eine Bestellung gebrauchter Siacoin-ASICs, denn die Hardware ist nicht exotisch, sondern seit Jahren im Handel. Genau das ist der Punkt, an dem Proof of Work seine Schutzwirkung aus der Höhe der aufgewendeten Arbeit zieht und nicht aus dem Algorithmus.

Auch im direkten Vergleich bleibt der Abstand gewaltig: Die Hauptkette stand am 14. September bei einer Difficulty von 127,45 Billionen, die Abspaltung bei 3,4 Milliarden. Die beiden Zahlen sind nicht unmittelbar vergleichbar, weil dahinter verschiedene Algorithmen stecken. Vergleichbar ist, was sie kosten — und das führt zurück auf die 910 EH/s.

Die finale Fassung ist da, der Pull Request bleibt ein Entwurf

Zwei offene Punkte aus unserem Beitrag vom 31. August lassen sich jetzt beantworten. Erstens: Bitcoin Knots 29.4.1 ist erschienen, allerdings am 2. September statt wie angekündigt am 1. Die Release Notes nennen den Algorithmuswechsel nüchtern "BLAKE2b proof-of-work algorithm (mitigates ongoing attack)" und führen daneben die befristete Blockgrenze von 800 kWU sowie mehrere behobene CVEs auf. Zweitens: Der von Luke Dashjr in Aussicht gestellte Rücksetzer auf Block 961.639 wurde nicht gebraucht. Die Kette läuft seit der Aktivierung durch.

Was sich dagegen nicht bewegt hat, ist Pull Request 359, der den Wechsel technisch trägt. Er steht weiterhin auf Draft, letzte Aktivität am 15. August, und die drei gemeldeten Prüfbefunde sind unverändert offen. Die Kette produziert also seit gut zwei Wochen Blöcke nach Regeln, deren Vorschlag formal noch nicht einmal zur Prüfung freigegeben ist. Wer das für eine Formalie hält, möge sich vor Augen führen, dass es bei einem Konsensbruch keine zweite Runde gibt.

Ein Pool, eine Börse — und eine Warnung vor dieser Börse

Für alle, die auf der Hauptkette minen, ändert das alles nichts: Der Bitaxe zeigt weiter auf den Pool eurer Wahl, bei uns auf stratum+tcp://blitzpool.yourdevice.ch:3333, und die Übersicht dazu steht in der kleinen Bitcoin Solo Mining Bibel. Auf der Abspaltung hat sich die Lage dagegen sortiert. Neben den Kleinstpools der ersten Tage gibt es inzwischen reguläre Angebote: B2Pool betreibt einen TIDES-Pool mit einem Prozent Gebühr und einer Mindestauszahlung von 10.000 Satoshi, dazu einen Solo-Zweig. Das Fachmedium Cryptolexicon beschreibt mit AlphaPool einen weiteren Anbieter mit PPLNS, 2,5 Prozent Gebühr und vier Relays in den USA, Europa und Singapur, der mit Antminer A3 und Goldshell SC ohne eigene Firmware arbeitet.

Auf der Handelsseite ist das Bild dünner. Am 2. September berichtete Bitcoin.com News von einer einzigen Börse, die BTCB2 listet, bei einem Tagesumsatz von rund 94.100 US-Dollar und einer Handelsspanne von 80 bis 176 Dollar an einem einzigen Vormittag. Bemerkenswert ist weniger der Kurs als die Begleitmusik: Eine Informationsseite aus dem Umfeld der Kette rät im selben Bericht ausdrücklich zur Vorsicht gegenüber genau dieser Börse. Kursangaben aus einem solchen Markt sagen nichts über einen Wert, und wir führen sie hier nur an, weil unsere Feststellung vom 31. August, es gebe für die Coins schlicht keinen Preis, damit überholt ist.

Die Seed-Masche ist zurück

Mit dem Handel kommt die Betrugswelle. Cryptolexicon weist darauf hin, dass im Umfeld der Kette die Behauptung kursiert, für den Erhalt von BTCB2 sei der Import der privaten Schlüssel oder der Seed-Phrase nötig. Das ist falsch. Es ist dieselbe Masche wie bei jeder Abspaltung seit 2017, und sie funktioniert, weil sie technisch halb plausibel klingt.

Der Sachverhalt dahinter: Beide Ketten teilen ihre Geschichte, dieselben Schlüssel gelten auf beiden. Genau deshalb öffnet eine Seed-Phrase, die ihr irgendwo eingebt, nicht nur die Fork-Coins, sondern auch eure echten Bitcoin. Wer eine Seed besitzt, auf der noch Guthaben liegt, bringt sie nirgendwo ein — nicht bei einem Pool, nicht bei einer Börse, nicht in einer Wallet, die Fork-Coins verspricht. Wer alte Bestände tatsächlich bewegen will, räumt zuerst alle echten Bitcoin auf eine neue, frisch erzeugte Wallet und fasst die alten Schlüssel erst danach an.

Für den Umgang mit den zugehörigen Phishing-Mails gilt unverändert, was wir zum BitBox-Phishing mit gültiger DKIM-Signatur geschrieben haben: Eine technisch korrekte Absenderprüfung sagt nichts darüber, ob der Inhalt stimmt.

Was die deutschsprachige Berichterstattung am 2. September schrieb

Am 2. September, also am Tag der zweiten Difficulty-Anpassung, meldete das Fachportal IT Boltwise, der Hardfork sei am 1. September gestartet und "nach Stunden zusammengebrochen", er habe kaum Rechenleistung angezogen. Beides lässt sich an der Kette nachzählen: Der Start war der 30. August, und statt eines Zusammenbruchs hat die Kette an genau jenem 2. September ihre zweite Anpassung am oberen Anschlag genommen.

Das ist kein Detail für Erbsenzähler. Wer eine Kette für tot erklärt, die produziert, unterschätzt sie zwangsläufig auch dort, wo Vorsicht angebracht wäre — etwa bei der Frage, wer auf ihr bezahlt wird und mit welchen Coins. Umgekehrt gilt dasselbe: Eine Kette, die Blöcke ausspuckt, ist deswegen nicht sicher. Beide Fehler entstehen aus derselben Bequemlichkeit, nämlich die Zahlen nicht nachzusehen, obwohl sie öffentlich sind.

Was das für euch heisst

Für den Bestand in eurer Wallet ändert sich nichts. Die Hauptkette läuft unverändert weiter, eure Schlüssel gelten dort wie vorher, und es gibt keinen Schritt, den ihr wegen dieser Abspaltung unternehmen müsstet.

• Nichts tun ist eine vollständige Antwort. Wer die Fork-Coins nicht will, muss dafür nichts einrichten, nichts importieren und nichts abholen.
• Die Seed bleibt, wo sie ist. Kein Werkzeug, kein Pool und keine Börse braucht sie, um euch etwas gutzuschreiben. Wer danach fragt, will das Guthaben auf der Hauptkette.
• Beim Mining zählt die Hardware, nicht der Name. SHA-256-Geräte können auf der BLAKE2b-Kette nicht rechnen. Wer dort minen will, braucht BLAKE2b-Hardware, und wer dafür Geld ausgibt, kauft sich in eine Kette mit einem Dreissigtausendstel der Absicherung ein.
• Beim Empfang von Zahlungen lohnt der Blick auf die Kette. Wer Bitcoin annimmt, sollte wissen, welche Node seine Zahlungseingänge bestätigt. Die Projektseite fordert Börsen ausdrücklich auf zu sagen, welche Kette sie gutschreiben — solange das nicht überall geschieht, ist die Frage berechtigt.

Fazit: Die Difficulty hat aufgeholt, die Sicherheit nicht

Die Kette hat den Test bestanden, der Ende August offen war. Sie produziert Blöcke, sie hat fünf Anpassungen durchlaufen, ihre Rechenleistung hat sich verzehnfacht, die finale Software ist erschienen, und der befürchtete Rücksetzer blieb aus. Das ist mehr, als ihr die meisten zugetraut haben, uns eingeschlossen.

Nur misst die Difficulty nicht, ob eine Kette Bestand hat, sondern nur, wie schwer der nächste Block zu finden ist. 31 PH/s gegen 910 EH/s, ein Pull Request im Entwurfsstadium, eine Börse mit Warnhinweis: Das ist der Stand nach elf Tagen Aufholjagd. Unsere Einschätzung vom 2. Juli bleibt deshalb unverändert. Eine Kette, deren gesamte Absicherung sich in zwei Wochen nachkaufen lässt, hat kein Difficulty-Problem gelöst, sondern nur ihr Blockproduktionsproblem — und das war nie das teure von beiden.

Die nächste Anpassung fällt bei Block 973.728 an. Wenn die Rechenleistung bleibt, dauert das diesmal die vorgesehenen zwei Wochen. Dann steht zum ersten Mal eine Zahl da, die nichts mehr aufholt, sondern etwas aussagt.

Quellen und weiterführende Links

• blake2bminer.com, Difficulty — alle fünf Anpassungen mit Block, Zeitpunkt und Faktor
• blake2bminer.com, Status — Aktivierung, Coinbase-Schlagzeile, Anschlag bei Faktor vier
• blake2bminer.com, Hashrate — Verlauf von rund 3 auf etwa 31 PH/s, Hardwarezahlen
• bitcoinknots/bitcoin, Release 29.4.1 und die zugehörigen Release Notes
• bitcoinknots/bitcoin, Pull Request 359 — Status Draft, letzte Aktivität 15.08.2026
• bitcoin/bitcoin, src/pow.cpp — die Begrenzung jeder Anpassung auf Faktor vier
• bitcoin-blake2b.org, FAQ — Datenlimits bis 1. September 2027, SIGHASH_UNIFIED, Hardware, Aufforderung an Börsen
• CoinWarz, Bitcoin Hashrate — Schätzung von 910 EH/s am 14.09.2026
• B2Pool — TIDES- und Solo-Mining auf der BLAKE2b-Kette
• Bitcoin.com News, 02.09.2026 — Listung, Umsatz und Warnhinweise
• Cryptolexicon — AlphaPool und die Seed-Falschbehauptung
• IT Boltwise, 02.09.2026 — der Bericht vom Zusammenbruch, gegen den sich die Zahlen halten lassen

The post BLAKE2b Difficulty: viermal am Anschlag, dann gebremst appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Schweiz hat den Start ihrer E-ID gestoppt, ohne einen neuen Termin zu nennen. Deutschland hat drei Monate später einen Termin genannt, ohne die verbindliche technische Richtlinie dafür veröffentlicht zu haben. Zwei Regierungen, dasselbe Vorhaben, zwei genau entgegengesetzte Entscheidungen – und daran lässt sich ziemlich gut ablesen, wie ernst es einem Staat mit der eigenen Identitätsinfrastruktur ist.

Wir haben an dieser Stelle schon zweimal über die europäische Brieftasche geschrieben, beide Male am Rand: einmal in der Bestandsaufnahme zur Altersverifikation auf Betriebssystemebene, einmal in dem Nachtrag über die EU-App, die zwei Minuten hielt. Dort stand am Schluss die Frage, wie lange die EUDI-Wallet halten wird, wenn es ernst wird. Diesmal geht es nicht um die Frage, sondern um die Technik darunter: was in so einer Brieftasche tatsächlich passiert, was das Gesetz dazu verlangt, und warum genau an dieser Stelle beide Länder gerade ihre Termine verschieben oder eben nicht.

Was die Schweiz am 30. Juni entschieden hat

Am 30. Juni 2026 hat der Bundesrat einen neuen Zeitplan für die Einführung der E-ID und der Vertrauensinfrastruktur bekanntgegeben. Bekanntgegeben ist dabei das freundliche Wort: Ein Einführungsdatum für die E-ID nennt die Mitteilung nicht, es werde später kommuniziert. Fest ist nur, dass die Vertrauensinfrastruktur „im ersten Halbjahr 2027 ihren Betrieb aufnehmen können“ soll.

Als Begründung nennt der Bund zwei Punkte, und beide sind technisch. Erstens: „Neueste Entwicklungen im Bereich der künstlichen Intelligenz bringen zusätzliche Herausforderungen für die Erstellung einer E-ID mit sich.“ Zweitens verstärkt das Bundesamt für Justiz den Online-Ausstellungsprozess mit weiteren technischen Vorkehrungen, um Schadsoftware zu erschweren und die Erkennung von Deepfakes zu stärken.

Das ist ein bemerkenswert unbequemes Eingeständnis. Der heikelste Moment im Leben einer digitalen Identität ist nicht ihre Benutzung, sondern ihre Ausstellung. Wer es schafft, sich mit einem gefälschten Gesicht und einem echten Ausweisfoto eine E-ID auf den Namen einer anderen Person ausstellen zu lassen, hat danach einen staatlich signierten Nachweis in der Hand, dem jeder Prüfer glaubt – weil er genau dafür gebaut wurde. Gegen diese Art von Angriff hilft keine Kryptographie im Nachhinein. Sie hilft nur davor.

Der Vorlauf dazu war knapp. Das E-ID-Gesetz wurde am 28. September 2025 an der Urne angenommen, und zwar, wie das Bundesamt für Justiz selbst festhält, „mit 50,39 Prozent Ja-Stimmen knapp“. Am 25. Februar 2026 kündigte der Bund deshalb vier zusätzliche Massnahmen an, um die Kritikpunkte der Gegnerschaft aufzunehmen – der Start war damals auf den 1. Dezember 2026 angesetzt. Am 21. April 2026 wies das Bundesgericht die Beschwerden gegen die Abstimmung ab; es ging dabei um verspätet gemeldete Zuwendungen von Ringier und der TX Group in der Höhe von rund 163'000 Franken, die dem Gericht nicht schwer genug wogen, wie die Nachrichtenagentur Keystone-SDA berichtete. Und Ende Juni war der Dezembertermin dann weg.

Was Deutschland am 9. September entschieden hat

Am 9. September 2026 hat das deutsche Digitalministerium BMDS Name und Startdatum der deutschen EUDI-Wallet bekanntgegeben. Sie heisst d-you und startet am 2. Januar 2027. Laut netzpolitik.org steht das „d“ für Digital und Deutschland und das „you“ für die einzelnen Nutzer. Über Namen lässt sich streiten, aber wer eine Ausweis-App nach dem Muster einer Streaming-Marke benennt, hat die Rollenverteilung vielleicht schon ganz gut verstanden.

Inhaltlich klingt die Ankündigung erst einmal gut. Die App soll ermöglichen, sich „online wie offline sicher auszuweisen, wichtige Dokumente digital zu verwalten und jederzeit selbstbestimmt über die eigenen Daten zu verfügen“. Sie soll „kostenlos und freiwillig nutzbar sein, während analoge Dienste weiterhin bestehen bleiben“, und persönliche Daten sollen nach Darstellung des Ministeriums ausschliesslich auf dem Smartphone gespeichert und verschlüsselt verarbeitet werden. Rechtsgrundlage ist das Digitale-Identitäten-Gesetz, das das Kabinett am 20. Mai 2026 beschlossen hat. Gebaut wird die App von einem Team aus der Bundesagentur für Sprunginnovationen, dem BSI, der Bundesdruckerei, Fraunhofer AISEC, PwC Deutschland und einer Kommunikationsagentur.

Der interessante Teil steht nicht in der Ankündigung, sondern daneben. Die verbindliche technische Grundlage für die deutsche Wallet ist die Technische Richtlinie TR-03189 des BSI. Sie legt nach eigener Beschreibung „verbindliche technische Vorgaben, Verfahren und Sicherheitsanforderungen“ fest und bestimmt, „wie die EUDI-Wallet gestaltet sein soll und welche Komponenten darin zusammenwirken“. Und sie befindet sich, Stand heute, „noch in Erstellung“ und ist „daher nicht öffentlich verfügbar“.

Rechnet das kurz nach: Knapp vier Monate vor dem Start ist das Dokument, das die Anforderungen an das Produkt definiert, nicht fertig. Die App wird nach Darstellung von netzpolitik.org bislang auch nicht sicherheitsgeprüft, und die Bundesregierung will „unter Berücksichtigung eventueller Restrisiken über den Start“ entscheiden. Die IT-Sicherheitsforscherin Bianca Kastl beschreibt das dort mit dem schönsten Bild, das dieser Text zu bieten hat: „Das ist ein wenig so, als würde man auf einem fahrenden Zug noch ein paar Sicherheitsingenieure holen.“

Zwei Länder, dasselbe Problem, zwei Reaktionen. Die Schweiz hat den Termin dem Sicherheitsstand angepasst. Deutschland passt den Sicherheitsstand dem Termin an. Das ist nicht Ländervergleich um des Vergleichens willen – es ist der einzige Unterschied, den ein Nutzer später überhaupt zu spüren bekommt.

Unverknüpfbarkeit steht in der Verordnung

Damit zur Technik, denn hier liegt der eigentliche Streit. Die europäische Grundlage ist die Verordnung (EU) 2024/1183, allgemein als eIDAS 2.0 bekannt. Sie verlangt von einer Brieftasche nicht nur, dass sie funktioniert, sondern beschreibt in ihren Erwägungsgründen ausdrücklich, wie sie sich zu verhalten hat.

Erwägungsgrund 32 verlangt Unbeobachtbarkeit: Anbieter von Brieftaschen „sollten Unbeobachtbarkeit gewährleisten, indem sie keine Daten erfassen und keinen Einblick in die Transaktionen der Nutzer der europäischen Brieftasche für die Digitale Identität haben“. Erwägungsgrund 59 definiert die selektive Offenlegung als Konzept, „das den Eigentümer von Daten dazu ermächtigt, nur bestimmte Teile grösserer Datensätze offenzulegen, damit der Empfänger nur diejenigen Informationen erhält, die für die Erbringung des von einem Nutzer angeforderten Dienstes notwendig sind“. Erwägungsgrund 56 bindet Abfragen an die Datenminimierung. Und Erwägungsgrund 60 hält fest, dass der Zugang zu Diensten unter Verwendung eines Pseudonyms nicht verboten sein sollte, solange keine Rechtsvorschrift eine Identifizierung verlangt.

Das ist, und das sei ausdrücklich gesagt, ein anständiger Anforderungskatalog. Wer nur die Schlagzeilen liest, erwartet von Brüssel etwas anderes. Datenminimierung, Pseudonyme, keine Einsicht des Betreibers in die Transaktionen – wenn eine Brieftasche das alles einhält, ist sie der Fotokopie eures Ausweises in jeder Hinsicht überlegen. Wer die Debatte um den digitalen Euro verfolgt hat, erkennt an dieser Stelle eine verwandte Frage wieder: Es kommt darauf an, was von einem Erwägungsgrund am Ende in der Spezifikation landet.

Und sie steht nicht im Protokoll

Am 19. Juni 2024 haben 16 international führende Kryptographen – unter ihnen Jan Camenisch, Anna Lysyanskaya und Bart Preneel – dem Architektur- und Referenzrahmen der EUDI-Wallet ein öffentliches Feedback geschrieben. Ihr Befund: Einige der damaligen Designentscheidungen fallen hinter die Datenschutzanforderungen der Verordnung zurück, weil sie auf kryptographischen Methoden beruhen, die für solche Anforderungen nie entworfen wurden.

Konkret geht es um die beiden Nachweisformate, die in Europa gesetzt sind: SD-JWT und die mobile Fahrerlaubnis nach ISO mDL. Beide können selektive Offenlegung – sie können also einzelne Merkmale zeigen und den Rest verbergen. Was sie nicht können, ist Unverknüpfbarkeit. Der Grund ist einfach und hat nichts mit schlampiger Umsetzung zu tun: In beiden Formaten wird eine feste Signatur des Ausstellers mitgeliefert, und diese Signatur ist bei jeder Vorweisung dieselbe Bytefolge. Zwei Prüfer, die ihre Protokolle vergleichen, sehen also nicht nur zwei Altersnachweise, sondern zweimal denselben. Die Kryptographen empfehlen deshalb BBS-Nachweise, eine seit über zwanzig Jahren erforschte Familie anonymer Nachweise, bei der jede Vorweisung eine frische, mathematisch unverknüpfbare Signatur trägt.

Was ist daraus geworden? Es gibt inzwischen eine eigene technische Spezifikation der EU zu Zero-Knowledge-Beweisen, Fassung 1.0 vom 21. Mai 2025, redaktionell aktualisiert am 30. Januar 2026. Ihr erster Absatz beantwortet die Frage vollständig: „At present, no existing ZKP approach can be deemed fully suitable or mature enough for direct integration into the EUDI Wallet.“ Das Dokument prüft die Verfahren, beschreibt die Lücken und ist erklärtermassen beschreibend, nicht vorschreibend.

Damit steht der Befund: Die Verordnung verlangt Unbeobachtbarkeit und Datenminimierung. Die Formate, mit denen sie umgesetzt wird, liefern Datenminimierung – und bei der Unverknüpfbarkeit eine organisatorische Zusage statt einer mathematischen Eigenschaft. Wer schon einmal eine eigene Zertifizierungsstelle für SSH aufgesetzt hat, kennt den Unterschied aus dem eigenen Serverraum: Eine Signatur, die überall gleich aussieht, ist genau deshalb so praktisch – und genau deshalb so gut wiedererkennbar.

Wie die Schweiz das umgeht: mehr Nachweise statt bessere Mathematik

Die schweizerische Vertrauensinfrastruktur benutzt dieselben Bausteine. Auf der Technologieseite des Bundes stehen sie namentlich: „Verifiable Credentials (SD-JWT VC), Decentralised Identifiers (DIDs), sowie OpenID for Verifiable Credential Issuance (OpenID4VCI) and Verifiable Presentations (OpenID4VP)“. Die technische Dokumentation zu swiyu nennt dieselben Formate und dazu Widerrufslisten für den Sperrstatus.

SD-JWT VC ist genau das Format, dessen Verknüpfbarkeit die Kryptographen kritisiert haben. Die Antwort des Bundes darauf ist nicht bessere Mathematik, sondern mehr Nachweise: „Selective disclosure and batch issuance ensure privacy and allow to reduce shared identity data.“ Batch Issuance heisst, dass die Wallet nicht einen Nachweis erhält, sondern einen ganzen Stapel gleichartiger Nachweise mit jeweils eigener Signatur, und für jede Vorweisung einen frischen davon verbraucht. In der Mitteilung vom 25. Februar 2026 steht derselbe Gedanke in Behördendeutsch: Eine Mehrfachausstellung unterschiedlicher E-IDs soll verhindern, dass Transaktionen verfolgt werden können.

Das ist ein ehrlicher Kompromiss, und er funktioniert – bis der Stapel leer ist. Ein Vorrat an Einmalnachweisen ist eine Ressource, und Ressourcen gehen zur Neige, müssen nachgeladen werden und erzeugen dabei wieder Verkehr zum Aussteller. Vor allem aber ist die Eigenschaft, die dabei herauskommt, eine andere als die, die die Verordnung beschreibt. Der Bund formuliert das selbst auffällig vorsichtig: „Linkability of usage across different services is technically restricted.“ Eingeschränkt, nicht ausgeschlossen. Wer solche Sätze schon einmal geschrieben hat, weiss, wie viel Arbeit in der Wortwahl steckt.

Was der Bund sieht und was nicht

Bevor jetzt die falsche Erzählung entsteht: Der Bund baut sich mit der E-ID keine Datenbank eurer Anmeldungen. Er betreibt laut eigener Beschreibung zwei Register, ein Basisregister und ein Vertrauensregister. Darin liegen „the identifiers and public keys of credential issuers and verifiers, information on their trust level, as well as information on a credentials state of revocation“. Und ausdrücklich: „Personal data contained in individual digital credentials is never stored in these registers.“ Auch der Aussteller erfährt aus diesem Aufbau nicht, wo ihr euren Nachweis später vorweist: Der Prüfer fragt nicht bei ihm nach, sondern liest den Sperrstatus aus einer Widerrufsliste, die laut Dokumentation keine Rückschlüsse auf Inhaber oder Inhalt eines Nachweises zulässt.

Dazu kommen die vier Massnahmen vom Februar 2026, und die sind ernst zu nehmen. Nur gesetzlich berechtigte Anbieter dürfen die AHV-Nummer abfragen, unautorisierte Anfragen blockiert die Wallet automatisch. Anbieter müssen ihre Datenabfragen in einem öffentlichen Register eintragen, und bei Verstössen werden Nutzer gewarnt. Das Bundesamt für Justiz kann fehlbare Anbieter aus dem System ausschliessen. Wer die Abstimmungsdebatte von 2025 mitgemacht hat, erkennt in dieser Liste Punkt für Punkt die Argumente der Gegnerschaft wieder – und das ist ein Kompliment, nicht eine Kritik.

Die Stelle, an der Daten zusammenlaufen können, ist damit nicht der Staat, sondern die Prüferseite. Ein Anbieter, der euren Altersnachweis sieht, sieht auch die Signatur, die Kennung des Nachweises und die Abfrage beim Sperrstatus. Mehrere Anbieter, die zusammenarbeiten wollen, brauchen dafür keine Behörde. Es ist derselbe Mechanismus, den wir bei Metadaten in Messengern beschrieben haben: Nicht der Inhalt verrät euch, sondern das Wiedererkennungsmerkmal am Rand.

Freiwillig, kostenlos, analog – und trotzdem die falsche Frage

Beide Länder betonen dasselbe Dreifachversprechen. Die deutsche Wallet soll „kostenlos und freiwillig nutzbar sein, während analoge Dienste weiterhin bestehen bleiben“. Für die Schweiz hält das Bundesamt für Justiz auf seiner Themenseite zur staatlichen E-ID Freiwilligkeit, Kostenlosigkeit, grösstmögliche Kontrolle über die eigenen Daten und Privacy by Design fest.

Diese Zusagen sind echt, und sie sind nicht wenig. Sie beantworten nur eine andere Frage als die, die sich stellt. Freiwilligkeit auf der Ausgabeseite sagt nichts über die Annahmeseite: Entscheidend ist nicht, ob ihr eine E-ID beantragen müsst, sondern ob es Dienste gibt, die ohne sie nicht mehr erreichbar sind. Wie dieser Hebel aussieht, wenn er einmal angesetzt wird, haben wir am Beispiel der Altersverifikation auf Betriebssystemebene in aller Länge beschrieben; das wird hier nicht wiederholt. Der Punkt für heute ist ein anderer und kleiner: Wenn die Verknüpfbarkeit einer Vorweisung nur organisatorisch eingeschränkt ist, dann hängt der Datenschutz eines freiwilligen Systems an dem Verhalten derjenigen, die es verlangen werden.

Nebenbei: Dass Bequemlichkeit die Bindung an eine Plattform erhöht, ist in diesem Feld keine neue Erkenntnis. Bei Passkeys hat genau dieser Mechanismus dazu geführt, dass ein Anmeldeverfahren mit sehr guten Sicherheitseigenschaften nebenher drei Konzern-Ökosysteme zementiert hat. Eine Brieftasche, die auf dem Smartphone lebt und aus dem App-Store zweier amerikanischer Unternehmen kommt, betrachtet ihr besser mit dieser Erfahrung im Hinterkopf.

Die Gegenposition, und was von ihr bleibt

Gegen diesen Text lassen sich mindestens drei gute Einwände formulieren, und sie gehören hierher.

Erstens: Der Vergleichsmassstab ist nicht das Ideal, sondern die Gegenwart. Heute schickt ihr für einen Altersnachweis ein Foto eures Ausweises an einen Drittanbieter, und der speichert es. Eine Brieftasche mit selektiver Offenlegung übermittelt stattdessen ein Merkmal. Selbst mit wiedererkennbarer Signatur ist das eine deutliche Verbesserung, und wer das Gegenteil behauptet, vergleicht mit einer Welt, in der niemand ein Alter nachweisen muss.

Zweitens: Batch Issuance ist keine Ausrede, sondern Stand der Technik. Wenn keine ZKP-Familie reif genug für den Einsatz auf Millionen Geräten mit Secure Elements ist – und das sagt die EU-Spezifikation selbst –, dann ist ein Stapel Einmalnachweise die beste heute lieferbare Annäherung. Eine Infrastruktur auf ein Verfahren zu setzen, dessen Hardwareunterstützung fehlt, wäre der schlechtere Fehler.

Drittens: Verzögerungen kosten auch etwas. Jedes Jahr ohne staatliche E-ID ist ein Jahr, in dem private Identitätsdienste, Ausweis-Uploads und Video-Identifikation weiterlaufen. Wer Sicherheit gegen Termine ausspielt, sollte die Kosten des Wartens mitnennen.

Diese Einwände halten – bis auf eine Stelle. Sie rechtfertigen alle den heutigen technischen Stand. Keiner von ihnen rechtfertigt, ein System als unverknüpfbar zu beschreiben, das es nicht ist. Genau das ist der Unterschied zwischen der schweizerischen und der deutschen Kommunikation: Der Bund schreibt „technically restricted“ und meint es. Das Versprechen „jederzeit selbstbestimmt über die eigenen Daten verfügen“ ist dagegen eine Zusage, die das Protokoll nicht hält, und sie steht in einer Ankündigung, deren technische Richtlinie noch nicht einmal geschrieben ist.

Was ich anders mache

Ich werde die E-ID nicht grundsätzlich ablehnen. Ein staatlich signierter Nachweis, der ein einzelnes Merkmal zeigt, ist mir lieber als ein Ausweisfoto im Kundendienstsystem einer Plattform. Was ich anders mache als die Gebrauchsanleitung es vorsieht, sind drei Dinge.

Ich behandle die Brieftasche als Ausweis, nicht als Konto. Ein Ausweis wird gezeigt, wenn jemand ein Recht hat, ihn zu sehen. Er wird nicht bei jeder Anmeldung vorgelegt, weil es schneller geht. Die Bequemlichkeit ist in diesem System die Falle, nicht das Geschenk.

Ich prüfe bei jeder Abfrage, wer fragt und was er will. Die Schweiz baut genau dafür ein öffentliches Register der Abfragen und eine Sperrmöglichkeit für fehlbare Anbieter. Ein Kontrollinstrument, das niemand benutzt, ist Dekoration. Wer eine Abfrage sieht, die mehr will als nötig, sollte sie ablehnen und melden.

Ich bleibe beim analogen Weg, solange es ihn gibt. Nicht aus Nostalgie, sondern weil die gesetzliche Zusage, dass analoge Dienste bestehen bleiben, nur so lange praktisch gilt, wie es Leute gibt, die sie nutzen. Ein Schalter, an dem niemand steht, wird geschlossen, und danach ist die Freiwilligkeit eine Formulierung im Gesetz und keine Wahlmöglichkeit mehr.

Fazit: Ein Termin ist keine Sicherheitseigenschaft

Die Schweiz hat im Juni ihren eigenen Starttermin gestrichen, weil der Ausstellungsprozess gegen Deepfakes und Schadsoftware nicht fest genug war. Das ist keine Panne, das ist die einzige richtige Reihenfolge: erst die Eigenschaft, dann das Datum. Deutschland macht es umgekehrt und hat dafür ein Datum, eine Kommunikationsagentur und einen Namen, aber keine veröffentlichte technische Richtlinie.

Und darunter liegt in beiden Ländern dieselbe offene Frage. Die Verordnung verlangt Unbeobachtbarkeit, die Formate liefern sie nicht, die zuständige Spezifikation sagt selbst, dass kein verfügbares Verfahren dafür reif ist, und die Praxis behilft sich mit einem Stapel Einmalnachweise. Das ist tragfähig genug für den Anfang und nicht tragfähig genug für die Sätze, die darüber gesagt werden.

Wer wissen will, wie gut eine digitale Identität wirklich ist, schaut deshalb nicht auf die Datenschutzerklärung, sondern auf zwei Dinge: ob die Signatur bei jeder Vorweisung eine andere ist, und ob die Richtlinie, die das vorschreibt, gelesen werden kann. Bei der Schweizer E-ID lautet die Antwort einmal „fast“ und einmal „ja“. Bei d-you lautet sie einmal „fast“ und einmal „noch nicht“. Die Zeit, die die Schweiz sich dafür genommen hat, ist das Billigste an dieser ganzen Infrastruktur.

Quellen und weiterführende Links

• Der Bundesrat: Neuer Zeitplan für die Einführung der E-ID und der Vertrauensinfrastruktur (30.06.2026)
• Bundesamt für Justiz: Akzeptanz der E-ID mit zusätzlichen Massnahmen stärken (25.02.2026)
• Bundesamt für Justiz: Staatliche E-ID
• eid.admin.ch: Technology – Standards der schweizerischen Vertrauensinfrastruktur
• swiyu: Technische Dokumentation, Einführung
• BMDS: EUDI-Wallet – d-you startet am 2. Januar 2027
• DIF-AG: Technische Richtlinie TR-03189 für die EUDI-Wallet
• netzpolitik.org: Neuer Name, alte Baustellen – die Hürden zum Start von d-you (10.09.2026)
• EUR-Lex: Verordnung (EU) 2024/1183 (eIDAS 2.0)
• Cryptographers' Feedback on the EU Digital Identity's ARF (19.06.2024)
• EU Digital Identity Wallet: Technical Specification 4 – Zero-Knowledge Proofs
• Keystone-SDA über swissinfo.ch: Bundesgericht lehnt Aufhebung der Abstimmung zur E-ID ab

The post E-ID Schweiz: verschoben ist besser als kaputt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

LG hat inzwischen reagiert, wie unter anderem CHIP berichtet. Mit einem Dementi, das bei genauem Lesen vor allem eines ist: eine Ausrede. In diesem Beitrag ordnen wir ein, was bei der LG Smart TV Überwachung belegt ist, was LG bestreitet, was LG verschweigt, und wir zeigen euch, wie ihr einen LG-Fernseher, der schon bei euch steht, per VLAN und Firewall-Regeln vom Internet und vom restlichen Heimnetz aussperrt.

Was die Recherche von Gamers Nexus zeigt

Gamers Nexus hat mehrere LG-OLED-Fernseher aus dem US-Handel untersucht, darunter das aktuelle Flaggschiff G5. Nach eigenen Angaben flossen über 500 Arbeitsstunden und mehr als 70'000 US-Dollar in das Projekt. Getestet wurde mit Paketmitschnitten und Firmware-Analysen, zusammen mit den Sicherheitsforschern MrBruh und uturn sowie Wendell von Level1Techs. Die Kernbefunde:

• Netzwerk-Inventur: Die Fernseher durchsuchen das lokale Netz nach Smartphones, Smartwatches, Druckern und anderer Hardware und protokollieren dabei die öffentliche IP des Haushalts sowie interne Adressen. Laut den Forschern werden zudem benachbarte WLAN-Netze und Standortdaten erfasst.
• Mikrofon mit Nachlauf: Nach einem Sprachbefehl bleibt das Mikrofon 10 bis 15 Sekunden aktiv, das Gesagte landet als Klartext-Transkript in Protokolldateien auf dem Gerät. Nebengeräusche wurden laut den Forschern bis in rund 12 Meter Entfernung mitgeschnitten.
• Offline-Puffer: Im Test speicherte ein Gerät Audio auch nach dem Ziehen des Netzwerkkabels weiter und lud die Dateien hoch, sobald die Verbindung zurück war.
• ACR bis in die HDMI-Eingänge: Die automatische Inhaltserkennung (ACR) erstellt Fingerabdrücke von Bild und Ton und erkennt so, was ihr schaut, auch von Geräten am HDMI-Eingang. Ein Testgerät schickte laut der Auswertung rund 4 GB ACR-Daten pro Monat nach Hause.
• Sicherheitslücken: Die Forscher konnten über eine Remote-Code-Execution-Lücke über das Mikrofon des Fernsehers mitschneiden. Die technischen Details liegen noch im Responsible-Disclosure-Fenster. Zusätzlich fand Wendell im Update-Programm eine hart kodierte IP-Adresse, die über unverschlüsseltes HTTP angesprochen wird.

Was man fairerweise sagen muss

Wer kritisch berichtet, muss präzise sein. Die dauerhafte Nutzung des Fernsehers als Wanze im Standby setzte in den gezeigten Szenarien eine Kompromittierung des Geräts voraus. Im Normalbetrieb geht es um die Protokollierung rund um Sprachbefehle. Auf dem von Wendell analysierten G5 war der ACR-Dienst zum Zeitpunkt der Untersuchung konfiguriert, aber nicht aktiv. Und die Zahl 216 Millionen ist kein Mass für belegte Abhörfälle, sondern LGs eigene Marketingzahl für die weltweite Smart-TV-Basis, in den USA sind es 49 Millionen Geräte. Getestet wurden US-Geräte; ob sich europäische Firmware identisch verhält, ist damit nicht belegt.

Genau diese Präzision fehlt aber in LGs Antwort. Denn das Problem ist nicht, dass LG nachweislich jedes Wohnzimmer rund um die Uhr abhört. Das Problem ist, dass LG ein Gerät gebaut hat, das es könnte, das Daten sammelt, die es für seine Funktion nicht braucht, und dessen Sicherheit so schwach ist, dass Dritte die Kontrolle übernehmen können.

LGs Dementi im Faktencheck

LG eröffnet seine Stellungnahme mit dem Satz, die Behauptungen im Video seien "nicht wahr". Liest man weiter, bleibt davon erstaunlich wenig übrig. LG bestätigt in derselben Mitteilung zwei zentrale Vorwürfe und schweigt zu mehreren anderen. Die vollständige Stellungnahme hat Tom's Hardware veröffentlicht.

Ausrede 1: "Keine Aufzeichnung von Umgebungsgesprächen"

LG betont, Sprachdaten würden nur verarbeitet, wenn die Mikrofontaste gedrückt oder "Hi LG" erkannt werde. Ansonsten zeichne der Fernseher keine Gespräche auf, nicht erkanntes Audio werde lokal verarbeitet und sofort gelöscht. Das ist ein klassisches Strohmann-Dementi. Der zentrale Befund war nicht, dass der TV permanent alles an LG streamt. Der Befund war, dass er nach einem Befehl weiter zuhört, das Gesagte transkribiert und im Klartext speichert. Genau dazu sagt LG nichts: Tom's Hardware hält ausdrücklich fest, dass LG auf die Klartext-Transkripte und weitere Punkte nicht eingegangen ist. Wer 10 bis 15 Sekunden Raumgespräch nach einem "Hi LG" protokolliert, zeichnet Umgebungsgespräche auf, egal wie die Pressestelle es nennt.

Und nebenbei bestätigt LG, dass der Fernseher im Standby auf das Weckwort lauscht, sofern die Fernfeld-Spracherkennung aktiv ist. "Ausgeschaltet" heisst bei LG also nicht aus. Der Informatiker Yash Vekaria von der UC Davis bringt den Kern auf den Punkt: Ein Sprachbefehl ist nur in Echtzeit nützlich. Wird Audio für einen späteren Upload zurückgehalten, dient es vermutlich einem anderen Zweck, etwa Analyse oder Training, und LG solle erklären, welchem. Diese Erklärung bleibt LG schuldig.

Ausrede 2: "Der Netzwerk-Scan ist eine Standardfunktion"

LG räumt den Scan des Heimnetzes ein und nennt ihn eine Funktion, die Smart-TVs und Smart-Home-Geräte üblicherweise mitbringen. Geräteerkennung für Screen-Mirroring braucht es tatsächlich. Nur: Erkennen ist nicht Inventarisieren. Um euer Smartphone als Cast-Quelle anzubieten, muss der Fernseher weder den Hersteller eures Thermostats noch die Namen der WLANs eurer Nachbarn protokollieren. Anna Maria Mandalari vom University College London weist darauf hin, dass solche Daten die Zusammensetzung eines Haushalts offenlegen und ein breiteres Profil der Bewohner ermöglichen.

Dass es genau darum geht, sagt LG Ad Solutions selbst. Julian Zilberbrand, dort für Datenlösungen verantwortlich, erklärte 2025, man wisse, wer im LG-Haushalt lebt und welche Geräte dort stehen. In den USA wirbt die Sparte mit 363 Millionen erreichbaren Zweitgeräten bei 49 Millionen Fernsehern. Eine "Standardfunktion" ist der Scan nur, wenn das Geschäftsmodell Werbung heisst.

Ausrede 3: "ACR ist Opt-in"

LG schreibt, Inhaltserkennung, Sprachdienste und interessenbasierte Werbung erforderten jeweils eine separate, ausdrückliche Zustimmung. Zwei Tatsachen relativieren das deutlich. Erstens hat sich LG im Mai 2026 in einem Vergleich mit dem Generalstaatsanwalt von Texas verpflichtet, ACR-Daten nicht mehr ohne informierte Zustimmung zu sammeln und dafür eine Pop-up-Erklärung einzubauen. Wer so etwas unterschreibt, hat es vorher offensichtlich nicht so gehandhabt, wie er es heute darstellt.

Zweitens zeigte der Test von Gamers Nexus ein differenziertes, aber wenig schmeichelhaftes Bild: Ohne akzeptierte Vereinbarungen übertrug das Testgerät zwar keine ACR-Daten, kontaktierte aber trotzdem LG-Werbe-Endpunkte und scannte weiter das Netz. Laut der Firmware-Analyse sendet der Fernseher beim Opt-out zudem einen letzten vollständigen Datenstand an Alphonso, und die angeblich anonyme Geräte-ID lässt sich mit dem modellspezifischen Schlüssel auf die MAC-Adresse zurückführen. Ein Opt-in, das beim Nein nochmals alles mitnimmt, verdient den Namen nicht.

Ausrede 4: "Datensicherheit hat höchste Priorität"

LG versichert, man überwache die Plattform kontinuierlich und arbeite mit unabhängigen Sicherheitsexperten zusammen. Dem stehen die Befunde gegenüber: eine Angriffskette, bei der laut Gamers Nexus ein einziger Klick auf eine gefälschte Kopplungsanfrage für Root-Zugriff genügt, ein Update-Mechanismus mit hart kodierter IP-Adresse und HTTP ohne Verschlüsselung, und ein physischer Mikrofonschalter, der nur das eingebaute Mikrofon abschaltet, während Fernbedienung, USB-Webcam oder Bluetooth-Geräte mit Root-Zugriff weiter mitgeschnitten werden konnten. Vekaria warnt, dass Fernseher oft jahrelang über das Ende ihres Update-Supports hinaus im Einsatz sind und schnelle Patches deshalb entscheidend sind. Einen konkreten Patch-Termin nennt LG nicht.

Ausrede 5: "Transparenz" und Absage an Dark Patterns

LG betont, man lehne irreführende Praktiken ab und setze sich für Transparenz ein. Gleichzeitig hat LG am 28. Juli 2026 seine US-Nutzungsbedingungen um eine verbindliche Schiedsklausel ergänzt, die den Weg vor ordentliche Gerichte einschränkt. Das geschah rund zwölf Tage, nachdem Gamers Nexus ein erstes Video zu LG veröffentlicht hatte. Transparenz sieht anders aus. Wer seinen Kunden vorsorglich den Gerichtsweg verbaut, rechnet offenbar mit Klagen.

Wer die Daten auswertet: LG Ad Solutions

LG Ad Solutions ist aus dem Datenunternehmen Alphonso hervorgegangen, an dem LG 2021 die Mehrheit übernommen hat; in LGs Vereinbarungen wird Alphonso als Partner genannt, der Sehdaten für Werbung erhebt und nutzt. Geführt wird die Werbesparte von Serge Matta. Die US-Börsenaufsicht SEC warf ihm und seinem früheren Arbeitgeber Comscore 2019 vor, Umsätze um rund 50 Millionen Dollar überhöht ausgewiesen zu haben. Matta einigte sich mit der SEC, ohne die Vorwürfe anzuerkennen oder zu bestreiten, zahlte 700'000 Dollar Busse, 2,1 Millionen an Comscore zurück und darf zehn Jahre lang keine börsenkotierte Firma führen (SEC-Verfügung). LG Ad Solutions ist nicht börsenkotiert.

Daraus muss man keine Verschwörung ableiten. Aber es sagt einiges über das Vertrauen aus, das ihr einem Konzern entgegenbringen sollt, dessen Datensparte so aufgestellt ist und dessen Chef öffentlich erklärt, der Bildschirm in eurem Wohnzimmer gehöre LG. Wer sehen will, wohin Profilbildung im grossen Stil führen kann, findet in unserem Beitrag zum Cambridge-Analytica-Skandal ein lehrreiches Beispiel.

Kein Einzelfall: ACR ist ein Branchenproblem

LG ist nur der aktuell am besten dokumentierte Fall. Vizio zahlte bereits 2017 2,2 Millionen Dollar an die FTC und den Staat New Jersey, weil es auf 11 Millionen Fernsehern ohne Zustimmung Sehgewohnheiten erfasst hatte. Im Dezember 2025 verklagte Texas Sony, Samsung, LG, Hisense und TCL wegen ACR; laut Klage können die Systeme alle 500 Millisekunden ein Bildschirmfoto auswerten. Eine wissenschaftliche Studie von 2024 hat ACR-Tracking auf Smart-TVs systematisch nachgewiesen. Gamers Nexus hat angekündigt, als Nächstes Geräte weiterer Hersteller zu testen. Wer jetzt einfach die Marke wechselt, wechselt deshalb meist nur den Datensammler.

Und in der Schweiz?

In der EU ist die Lage vergleichsweise klar: DSGVO und das deutsche TDDDG verlangen eine aktive Einwilligung, bevor ein Gerät Daten ausliest oder speichert. In der Schweiz ist das anders. Das Datenschutzgesetz kennt kein grundsätzliches Einwilligungserfordernis, auch nicht beim Profiling. Nur wenn eine Bearbeitung auf eine Einwilligung gestützt wird und es um ein "Profiling mit hohem Risiko" geht, muss diese nach Art. 6 Abs. 7 DSG ausdrücklich erfolgen. Dazu kommt die Pflicht zu datenschutzfreundlichen Voreinstellungen nach Art. 7 DSG.

Ob die Kombination aus Sehverhalten, Geräte-Inventar und Haushaltsprofil als Profiling mit hohem Risiko gilt, ist bisher nicht gerichtlich geklärt. Unsere Einschätzung, ausdrücklich keine Rechtsberatung: Daten, die offenlegen, wer in einem Haushalt lebt, was er schaut und welche Geräte er besitzt, betreffen wesentliche Aspekte der Persönlichkeit. Der Vergleich mit Texas gilt jedenfalls nur für Texas. Wer sich beschweren will, kann sich an den Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) wenden. Dass die Schweiz bei der Regulierung grosser Tech-Konzerne gerne hinterherhinkt, haben wir schon beim Digital Markets Act beschrieben.

Ihr habt schon einen LG-Fernseher? So sperrt ihr ihn aus

Wegwerfen muss niemand etwas. Die Panels von LG sind hervorragend, das Problem ist die Software. Das Ziel ist deshalb, aus dem Smart-TV ein möglichst dummes Display zu machen. Je nachdem, wie viel Netzwerk-Know-how und welche Hardware ihr habt, gibt es drei Stufen.

Stufe 1: Einstellungen (das Minimum, das nicht reicht)

Diese Schritte kosten ein paar Minuten und reduzieren die Datensammlung. Die Menüpfade unterscheiden sich je nach webOS-Version leicht:

• Live Plus (ACR) deaktivieren: Einstellungen → Allgemein → System → Zusätzliche Einstellungen → Live Plus aus (Anleitung mit Pfaden).
• Benutzervereinbarungen widerrufen: Einstellungen → Support → Datenschutz & Bedingungen → Benutzervereinbarungen, alle optionalen Vereinbarungen ablehnen.
• Werbung und Werbe-ID: interessenbasierte Werbung abschalten und die Werbe-ID zurücksetzen.
• Sprachdienste komplett aus: Fernfeld-Spracherkennung und Sprachassistent im Menü für KI-Dienste deaktivieren, nicht nur per Fernbedienung stummschalten. Nach LGs eigener Darstellung lauscht der TV dann im Standby nicht mehr.

Verlassen solltet ihr euch darauf nicht. Die Forscher konnten deaktivierte Sprachfunktionen über die Kommandozeile wieder einschalten, und Updates oder neue Nutzungsbedingungen können Einstellungen zurücksetzen. Menüschalter sind ein Versprechen des Herstellers, keine technische Garantie.

Stufe 2: Kein Netzwerk, eigener Zuspieler

Die klarste Lösung empfiehlt auch Wendell von Level1Techs als erste Wahl: alle Vereinbarungen ablehnen und den Fernseher als dummes Display nutzen. Netzwerkkabel ab, gespeicherte WLAN-Profile löschen, WLAN deaktivieren. Achtet darauf, dass der TV sich nicht in offene WLANs oder Community-Hotspots des Providers einbucht, auf diese Falle weisen die Forscher ausdrücklich hin. Gestreamt wird über ein externes Gerät, das ihr kontrolliert, etwa einen kleinen Linux-PC mit Kodi oder einem Jellyfin-Client. Bedenkt dabei: Auch gängige Streaming-Sticks sammeln Daten. Ein Tausch des Datensammlers ist kein Gewinn.

Wichtig: Einmal offline heisst dauerhaft offline. Da das Testgerät Audio lokal puffert und nach der Wiederverbindung hochlädt, holt ein kurzes "nur schnell ein Update" im Zweifel alles nach, was sich angesammelt hat.

Stufe 3: Eigenes VLAN und Firewall-Regeln

Wer eine richtige Firewall wie pfSense, OPNsense oder OpenWrt betreibt, kann den Fernseher gezielt einsperren. Das ist die Lösung für alle, die ihn nicht komplett offline nehmen wollen oder mehrere Smart-Geräte im Haus haben. Das Prinzip: Der TV bekommt ein eigenes Netz, sieht eure anderen Geräte nicht mehr, darf nur euren eigenen DNS-Resolver fragen und kommt standardmässig nicht ins Internet. Falls ihr mit VLANs noch nicht vertraut seid, lest vorher unseren Beitrag Was ist ein VLAN.

1. IoT-VLAN anlegen. Legt ein eigenes VLAN für den Fernseher an, zum Beispiel VLAN 30, und hängt den TV per Kabel an einen Switch-Port in diesem VLAN. WLAN am Fernseher aus. Allein damit ist der Netzwerk-Scan entschärft: Der TV findet in seinem Segment nichts ausser sich selbst. Schaltet mDNS- und SSDP-Weiterleitungen (etwa den Avahi-Reflector) zwischen den Netzen ab. Der Preis dafür: Casting vom Smartphone funktioniert dann nicht mehr.

2. DNS erzwingen. Manche webOS-Firmwares ignorieren den per DHCP verteilten DNS-Server und fragen hart kodiert bei 8.8.8.8 oder ähnlichen Resolvern. Eine NAT-Regel leitet deshalb jede DNS-Anfrage aus dem IoT-Netz auf euren eigenen Resolver um. DNS-over-TLS und DNS-over-QUIC laufen über Port 853 und werden gesperrt. Gegen DNS-over-HTTPS hilft eine Sperrliste bekannter DoH-Server; pfBlockerNG bringt dafür eine eigene Option mit.

3. Hart kodierte IP-Adressen sperren. Das Update-Programm nutzt als Rückfallebene die feste Adresse 156.147.69.32 auf Port 8080, genau dann, wenn die DNS-Auflösung scheitert. Zusätzlich beobachtete Wendell eine Telemetrie-Verbindung zu 54.186.247.229 bei AWS. Diese Adressen erwischt keine DNS-Sperre, nur die Firewall. AWS-Adressen können sich ändern, prüft das also regelmässig.

4. Regeln setzen. Ein Beispiel für pfSense, auf dem Interface des IoT-VLANs, die Reihenfolge ist entscheidend:

# Aliase (Firewall → Aliases)
LG_HARDCODED  = 156.147.69.32, 54.186.247.229
RFC1918       = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

# NAT → Port Forward (Interface IOT): DNS-Umleitung
IOT net  →  !IOT address  TCP/UDP 53   Redirect target 127.0.0.1 : 53

# Firewall → Rules → IOT
1  Pass    IOT net → IOT address     TCP/UDP 53     DNS nur zum eigenen Resolver
2  Reject  IOT net → LG_HARDCODED    any            hart kodierte LG-Adressen
3  Reject  IOT net → any             TCP/UDP 853    DoT / DoQ
4  Reject  IOT net → RFC1918         any            kein Zugriff aufs Heimnetz
5  Pass    IOT net → any             TCP 80,443     NUR falls Apps gebraucht werden
6  Reject  IOT net → any             any            alles andere

Ein paar Hinweise dazu. Nutzt Reject statt Block: Bei stillem Verwerfen wartet der Fernseher beim Start auf Timeouts und wird zäh, ein Tipp aus der Level1Techs-Community. Vergesst IPv6 nicht: Entweder deaktiviert ihr IPv6 im IoT-VLAN oder ihr spiegelt alle Regeln für IPv6. Sonst läuft der Verkehr einfach an euren IPv4-Regeln vorbei. Wer den TV ganz offline will, lässt Regel 5 weg. Bei OPNsense funktioniert das identisch, bei OpenWrt legt ihr eine eigene Zone "iot" an, verbietet das Forwarding ins LAN und ins WAN und leitet Port 53 per Redirect-Regel auf den Router um.

5. Falls ihr doch Apps braucht: DNS-Sperrliste. Wer Regel 5 aktiv lässt, sollte die LG-Endpunkte im eigenen Resolver sperren, zum Beispiel mit Pi-hole, AdGuard Home oder dem DNS-Resolver von pfSense. Wendells auf einem G5 verifizierte Liste umfasst unter anderem:

# Telemetrie
nextlgsdp.com
lgtvcommon.com
# Werbung
lgsmartad.com
# ThinQ / IoT
lgtviot.com
lgthinq.com
# OS-Updates (bewusst, siehe unten)
snu.lge.com
su.lge.com
su-ssl.lge.com
nsu.lge.com
# KI-Plattform
ngfts.lge.com

# NICHT pauschal lge.com sperren, sonst fällt der Content Store aus.
# lgtvsdp.com und lgappstv.com sperren nur, wenn ihr auf den Store verzichtet.

Gepflegte Sperrlisten in Stufen gibt es auch als Community-Projekt auf GitHub. Rechnet damit, dass LG Domains ändert. Eine DNS-Sperre ist ein Katz-und-Maus-Spiel, die Default-Deny-Regel der Firewall nicht.

Kontrolle: Vertrauen ist gut, Mitschnitt ist besser

Prüft nach der Einrichtung, ob der Fernseher wirklich schweigt. Im Query-Log von Pi-hole oder im Firewall-Log seht ihr, welche Domains angefragt und welche Verbindungen abgewiesen werden. Hart kodierte IP-Adressen tauchen im DNS-Log nicht auf, dafür braucht ihr einen Blick auf den Verkehr selbst, etwa mit tcpdump auf dem IoT-Interface. Wie das geht, zeigen wir in Netzwerkverkehr mit tcpdump überwachen.

# alles vom TV ausser DNS anzeigen (Interface und IP anpassen)
tcpdump -ni igb0.30 host 192.168.30.20 and not port 53

Was die Firewall nicht kann

Eine Firewall verhindert, dass Daten das Haus verlassen. Sie verhindert nicht, dass der Fernseher lokal protokolliert oder bei aktiver Spracherkennung auf das Weckwort lauscht. Deshalb gehören Stufe 1 und Stufe 3 zusammen. Und es bleibt ein ehrliches Dilemma: Wer Updates sperrt, bekommt auch keine Sicherheitspatches für die gefundenen Lücken. Für einen Fernseher ohne jeden Internetzugang ist das vertretbar, denn die gezeigten Angriffe brauchen Netzwerkzugang, den Browser oder eine Kopplungsanfrage. Wer den TV mit Apps online betreibt, sollte Updates gezielt freigeben, sobald LG die Lücken schliesst, und die Sperre danach wieder aktivieren.

Für sehr erfahrene Nutzer gibt es noch eine vierte Stufe: den Fernseher mit Werkzeugen der webOS-Homebrew-Community rooten und die Einwilligungen direkt in den Konfigurationsdateien ablehnen. Wendell beschreibt das mitsamt Skripten. Das geschieht auf eigenes Risiko, ein Werksreset setzt alles zurück, und ein Firmware-Update kann den Root-Zugang jederzeit schliessen. Die Firewall auf eurem Router ist die einzige Schicht, die jeden Reset überlebt.

Häufige Fragen zur LG Smart TV Überwachung

Hört mein LG-Fernseher mich ab?

Belegt ist, dass LG-Fernseher bei aktiver Fernfeld-Spracherkennung auch im Standby auf das Weckwort lauschen und nach einem Befehl weitere Sekunden mitprotokollieren. Ein permanentes Abhören des Raumes wurde im Normalbetrieb nicht nachgewiesen, war aber nach einer Kompromittierung des Geräts technisch möglich. Wer die Sprachdienste nicht nutzt, sollte sie komplett abschalten.

Reicht es, Live Plus auszuschalten?

Nein. Live Plus stoppt nach LGs Angaben die Nutzung der ACR-Daten für Werbung. Netzwerk-Scan, Kontakt zu Werbe-Endpunkten und Telemetrie laufen laut den Tests auch ohne akzeptierte Vereinbarungen weiter. Nur ein Fernseher ohne Internetzugang oder hinter einer restriktiven Firewall ist wirklich still.

Hilft der Mikrofonschalter am Fernseher?

Nur teilweise. Der Schalter deaktiviert das eingebaute Mikrofon. Die Forscher konnten mit Root-Zugriff trotzdem über die Fernbedienung, angeschlossene USB-Webcams oder Bluetooth-Geräte mitschneiden. Entfernt deshalb nicht benötigtes Zubehör mit Mikrofon.

Sind Fernseher anderer Hersteller besser?

Nicht grundsätzlich. ACR setzen praktisch alle grossen Hersteller ein, Texas hat neben LG auch Samsung, Sony, Hisense und TCL verklagt. Die hier beschriebenen Firewall-Massnahmen funktionieren herstellerunabhängig und sind für jeden Smart-TV sinnvoll. Weitere Grundlagen findet ihr in unserem Ratgeber zum Schutz der Privatsphäre.

Fazit: Holt euch das Glas zurück

LGs Stellungnahme widerlegt vor allem Vorwürfe, die in dieser Form niemand erhoben hat, bestätigt nebenbei den Netzwerk-Scan und das Lauschen im Standby und schweigt zu allem, was wirklich unangenehm ist: Klartext-Protokolle, Datenverkehr ohne Zustimmung, hart kodierte Update-Adressen und kritische Sicherheitslücken. Das ist keine Aufklärung, das ist Schadensbegrenzung. Wer kurz vorher die Nutzungsbedingungen um eine Schiedsklausel ergänzt und sich in Texas zu einem Einwilligungsdialog verpflichten lassen musste, kann sich nicht glaubwürdig auf Transparenz berufen.

"We own the glass", sagt LG Ad Solutions. Die Antwort darauf ist nicht Empörung, sondern Technik: Nehmt dem Fernseher den Blick ins Netz. Ein eigenes VLAN, eine Default-Deny-Regel und ein erzwungener DNS-Resolver sind an einem Nachmittag eingerichtet und machen aus dem Datensammler das, was ihr eigentlich gekauft habt: einen sehr guten Bildschirm. Und beim nächsten Kauf lohnt sich die Frage, ob es wirklich ein Smart-TV sein muss.

The post LG Smart TV Überwachung: Warum LGs Dementi nur eine Ausrede ist appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Update: aktuell scheinen auch angebliche Mails von Trezor und Cointracking zu kommen.

Das Wichtigste in Kürze

• Betreff der Mail: Critical Security Alert: Microcontroller Entropy Vulnerability, angeblicher Absender BitBox, Antwortadresse no-reply@shiftcrypto.ch.
• Behauptet wird ein Werksdefekt im Mikrocontroller, der den Hardware-Zufallsgenerator deterministisch mache. Ein Link führt auf ein angebliches entropy check tool im Browser.
• Der Inhalt hält technisch nicht stand. Das Ziel ist erkennbar, die Wiederherstellungswörter abzugreifen.
• Der Header dagegen ist sauber signiert und DMARC-konform. Es handelt sich nicht um eine einfache Absenderfälschung.
• Wenn ihr eine solche Mail erhaltet: nicht klicken, nichts eingeben, Mail aufbewahren und melden.

Was in der Mail steht

Die Nachricht ist sauber gestaltet und im Layout einer offiziellen Sicherheitsmitteilung gehalten. Das Engineering-Team habe eine kritische Schwachstelle auf Hardware-Ebene entdeckt, heisst es darin. Betroffen seien Geräte mit den Firmware-Versionen 9.21.0, 9.20.1, 9.19.0, 9.18.2 und 9.17.0. Der Fehler stamme vom Hersteller des Mikrocontrollers und liege nicht in der Firmware. Als Folgen werden genannt: zu wenig Zufall bei der Erzeugung der Wiederherstellungswörter, Angreifbarkeit per Brute Force und deterministische Hardware-Ausgaben bei bestimmten Produktionschargen.

Darunter steht ein Link mit der Aufschrift Launch the entropy check tool, ergänzt um den Hinweis, bei blockierten Links die Browser-Ansicht zu nutzen. Genau das ist der Angriff. Ein solches Werkzeug prüft nichts, es sammelt ein.

Warum der Inhalt technisch nicht aufgeht

Erstens hängt der Seed einer BitBox02 nicht an einem einzelnen Zufallsgenerator. Nach dem Bedrohungsmodell von BitBox kombiniert die Firmware die Zufälligkeit des Mikrocontrollers und des Secure Chips mit einer im Werk erzeugten Zufallskomponente, mit Zufälligkeit vom angeschlossenen Computer und mit dem Geräte-Passwort. Ein defekter Hardware-Zufallsgenerator allein ergibt daraus keinen erratbaren Seed. Das ist bewusst so gebaut, weil sich Zufälligkeit von aussen nie vollständig überprüfen lässt.

Zweitens stimmen die Versionsnummern nicht. Die genannten Versionen sind längst überholt, aktuell ist die 9.26er-Reihe. Der Bootloader-Fix kam mit dem Oeschinen-Release in Firmware 9.26.3. Wer eine echte Advisory schreibt, nennt aktuelle Versionen.

Drittens passt das Timing zu gut. Nach der RNG-Schwachstelle bei Coldcard und dem Dixence-Update ist das Thema Entropie in aller Munde. Decrypt berichtete Ende August über die von BitBox selbst offengelegten Firmware-Fehler. In der Stellungnahme zur Coldcard-Lücke warnt BitBox ausdrücklich davor, dass Angreifer solche Sicherheitsmeldungen aufgreifen, um Dringlichkeit zu erzeugen. Genau das passiert hier.

Viertens, und das macht alles Weitere überflüssig: BitBox fragt niemals nach den Wiederherstellungswörtern. Diese gehören nie in einen Computer, ein Smartphone, eine Webseite, eine Browser-Erweiterung, einen Passwortmanager, einen Cloud-Dienst oder einen KI-Chatbot, sondern ausschliesslich direkt auf das Gerät.

Der brisante Teil: der Mail-Header

Frühere Wellen liessen sich leicht entlarven. Bei der Phishing-Welle von 2024 reichte ein Blick auf die Absenderadresse, und BitBox konnte damals festhalten, dass die Mail nicht von einer BitBox-Adresse stammte. Diese Mail ist anders. Die Prüfung durch unseren eigenen Mailserver ergibt folgendes Bild:

Die Mail wurde also mit einem gültigen DKIM-Schlüssel für bitbox.swiss signiert und ist DMARC-konform ausgerichtet. Eine reine Absenderfälschung sieht anders aus, die scheitert genau an dieser Stelle. Auch eine Tippfehler-Domain scheidet aus, die Signaturdomain lautet exakt bitbox.swiss.

Zwei mögliche Erklärungen

Von aussen lässt sich nicht abschliessend beurteilen, was dahintersteckt. Nach unserem Kenntnisstand bleiben im Wesentlichen zwei Möglichkeiten:

1. Ein Konto beim Versanddienstleister Brevo, in dem bitbox.swiss als authentifizierte Absenderdomain hinterlegt ist, wurde übernommen und für den Versand missbraucht.
2. Der DKIM-Selector mail bei bitbox.swiss gehört zu einem Dienst, der kompromittiert, veraltet oder falsch konfiguriert ist.

Beides wäre ein Vorfall auf Infrastrukturebene und hätte nichts mit den Geräten selbst zu tun. Die Schlüssel bleiben auf der Hardware-Wallet, eine missbrauchte Mailingliste erreicht sie nicht. Einen vergleichbaren Fall gab es 2022 mit dem Datenleck bei ActiveCampaign, damals ging es allerdings um abgeflossene Adressen und nicht um authentifizierten Versand.

Wir haben BitBox über den Befund informiert und den vollständigen Quelltext angeboten. Sobald eine Rückmeldung vorliegt, aktualisieren wir diesen Artikel.

Die Mail ist zu 100% Betrug

Klickt man auf den Link (was man auf keinen Fall ohne VPN tun sollte) landet man natürlich auf einer Webseite die nach der Wörtern und der Passphrase fragt:

Nochmals, gebt auf keinen Fall Eure Recovery Phrase ein, dass wird dazu führen dass ihr all Eure Sats verliert!

Was ihr jetzt tun solltet

• Nicht klicken. Weder den Link noch die Browser-Ansicht. Externe Inhalte blockiert lassen.
• Nichts eingeben. Kein Wallet-Backup, keine 24 Wörter, keine abgetippte Kopie, kein Foto davon. Wer danach fragt, ist ein Angreifer.
• Firmware regulär aktualisieren, aber ausschliesslich über die BitBoxApp oder über bitbox.swiss, die Adresse von Hand eingetippt.
• Falls ihr Wörter eingegeben habt: sofort eine neue Wallet auf einem sauberen Gerät erstellen und das Guthaben dorthin transferieren. Der alte Seed ist verbrannt. Der Phishing-Leitfaden von BitBox beschreibt das Vorgehen im Detail.

Einordnung

Die übliche Empfehlung, den Absender zu prüfen, greift bei dieser Mail zu kurz. Wenn SPF, DKIM und DMARC alle bestehen, hilft der Blick auf die Absenderzeile nicht mehr weiter. Dann bleibt nur der Inhalt selbst als Prüfstein, und der ist zuverlässig: Eine Aufforderung, Wiederherstellungswörter irgendwo einzugeben oder prüfen zu lassen, ist immer ein Angriff. Ohne Ausnahme, ohne Ansehen des Absenders, unabhängig davon, wie gut die Mail signiert ist.

Das ist der eigentliche Grund, warum eine Hardware-Wallet funktioniert. Sie verlagert das Vertrauen weg von E-Mails, Webseiten und Support-Kanälen hin zu einem Gerät in eurer Hand. Diese Eigenschaft ist genau so viel wert, wie ihr sie verteidigt.

The post BitBox-Phishing-Mail besteht die DKIM-Prüfung: Warnung vor dem angeblichen Entropie-Bug appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung setzt voraus, dass ihr euch schon einmal per Schlüsselpaar bei einem Server angemeldet habt. Darauf baut alles auf, was hier folgt — ein Zertifikat ersetzt das Schlüsselpaar nicht, es kommt oben drauf. Wir richten eine eigene Zertifizierungsstelle ein, signieren damit Benutzer- und Hostschlüssel, begrenzen deren Rechte und Laufzeit und widerrufen sie am Ende wieder. Alles mit Bordmitteln von OpenSSH, ohne Zusatzsoftware und ohne fremden Dienst.

Warum SSH-Zertifikate das Problem mit authorized_keys lösen

Die klassische Anmeldung per öffentlichem Schlüssel ist eine Liste. Auf jedem Server steht in ~/.ssh/authorized_keys, welche Schlüssel dort hineindürfen. Ab dem dritten Server wird daraus eine Matrix: Jeder Schlüssel muss auf jeden Server, jede Änderung überall nachgezogen werden.

Das eigentliche Problem ist aber nicht das Hinzufügen, sondern das Wegnehmen. Ein einmal verteilter Schlüssel bleibt gültig, bis ihn jemand aktiv entfernt — auf jedem einzelnen Server. Verschwindet ein Notebook, beginnt eine Suchaktion durch Rechner, die vielleicht gerade gar nicht laufen. Ein öffentlicher Schlüssel hat kein Ablaufdatum, keinen Besitzer und keine Rolle. Er ist einfach da.

Ein Zertifikat dreht das um. Dem Server wird einmalig gesagt, welcher Zertifizierungsstelle er glaubt. Danach zählt kein einzelner Schlüssel mehr, sondern nur noch: Ist dieses Zertifikat von der richtigen Stelle unterschrieben, ist es noch gültig, und steht darin ein Name, der hier etwas zu suchen hat? Wer geht, bekommt kein neues mehr — und das alte läuft von allein ab.

Was ein Zertifikat ist — und was es ausdrücklich nicht ist

Das Verfahren ist keine Neuerung. OpenSSH hat es mit Version 5.4 am 8. März 2010 eingeführt: "Add support for certificate authentication of users and hosts using a new, minimal OpenSSH certificate format (not X.509)." Es steckt also seit über fünfzehn Jahren in jedem halbwegs gepflegten System.

Der Klammerzusatz ist wichtig. Ein SSH-Zertifikat hat mit den X.509-Zertifikaten, die euer Browser für HTTPS auswertet, nichts zu tun — kein gemeinsames Format, keine gemeinsame Werkzeugkette, keine Wurzelzertifikate von Dritten. Die Entwickler begründen das in der Formatbeschreibung PROTOCOL.certkeys so: "SSH eschews the use of X.509 certificates and uses raw keys. This approach has some benefits relating to simplicity of configuration and minimisation of attack surface." Weniger Angriffsfläche durch weniger Format — eine Begründung, die in dieser Branche selten zu lesen ist.

Was drinsteht, beschreibt die Handbuchseite ssh-keygen(1) knapp: "Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key." Es gibt zwei Sorten: Ein Benutzerzertifikat weist einen Benutzer gegenüber einem Server aus, ein Hostzertifikat den Server gegenüber dem Benutzer. Beide entstehen mit demselben Werkzeug und sind unabhängig voneinander nutzbar.

Principals: der Name, auf den es ankommt

Der wichtigste Teil eines Zertifikats sind die Principals. Bei einem Benutzerzertifikat sind das Namen, unter denen sich der Inhaber anmelden darf. Bei einem Hostzertifikat sind es Rechnernamen; laut ssh-keygen(1) gilt dort: "For host certificates, principals are hostnames and may include wildcards."

Ein Principal ist nicht zwingend ein Unix-Benutzername. Er kann eine Rolle sein — deploy, dba, backup —, und der Server entscheidet getrennt davon, welche Rolle sich als welcher Benutzer anmelden darf. Darauf kommen wir in Schritt 4 zurück.

Critical Options und Extensions

In einem Zertifikat stehen ausserdem Einschränkungen und Erlaubnisse, und die sind in zwei Töpfe geteilt. PROTOCOL.certkeys erklärt den Unterschied: "critical options are used to control features that restrict access where extensions are used to enable features that grant access. This ensures that certificates containing unknown restrictions do not inadvertently grant access while allowing new protocol features to be enabled via extensions without breaking certificates' backwards compatibility."

Praktisch heisst das: Eine critical option, die ein alter Server nicht kennt, lässt ihn das Zertifikat ablehnen. Eine unbekannte extension ignoriert er. Einschränkungen fallen im Zweifel zu eurem Vorteil aus, Erlaubnisse im Zweifel weg — genau so herum soll es sein.

Was ihr für diese Anleitung braucht

• Mindestens einen Linux-Server mit OpenSSH-Server und funktionierendem Schlüssel-Login, dazu einen Arbeitsrechner mit OpenSSH-Client.
• Einen dritten, möglichst gut abgesicherten Ort für den CA-Schlüssel. Ein verschlüsselter USB-Stick genügt, ein zweiter Rechner ist besser.
• Einen zweiten Zugangsweg zum Server für den Notfall: eine offene zweite SSH-Sitzung, eine Konsole beim Anbieter oder physischen Zugriff.

Die Befehle sind für Debian und Ubuntu geschrieben und laufen auf anderen Distributionen genauso; nur Pfade und Paketnamen können abweichen.

Schritt 1: Die CA erzeugen und sofort wegsperren

Eine Zertifizierungsstelle ist bei OpenSSH nichts anderes als ein normales Schlüsselpaar — kein eigenes Format, kein Dienst, keine Datenbank. Erzeugt wird sie auf dem Rechner, auf dem sie später bleiben soll, nicht auf dem Server, den ihr damit absichern wollt:

mkdir -p ~/ssh-ca && chmod 700 ~/ssh-ca
cd ~/ssh-ca
ssh-keygen -t ed25519 -f user_ca -C "user-ca yourdevice"
ssh-keygen -t ed25519 -f host_ca -C "host-ca yourdevice"

Zwei getrennte Schlüssel, einer für Benutzer- und einer für Hostzertifikate. Technisch ginge auch einer. Tut es nicht: Wenn ihr den Host-Schlüssel später auf ein Provisionierungssystem legt, soll damit nicht zugleich der Benutzerzugang unterschrieben werden können.

Vergebt für beide Schlüssel eine Passphrase. Das ist hier keine Geschmacksfrage wie beim Anmeldeschlüssel. Wer diese Datei ohne Passphrase in die Hände bekommt, kann sich selbst ein gültiges Zertifikat für jeden eurer Server ausstellen, und ihr merkt es nicht. Prüft anschliessend die Rechte — die privaten Dateien gehören ausschliesslich euch, wie in unserem Beitrag zu Gruppen und Berechtigungen unter Linux beschrieben:

chmod 600 ~/ssh-ca/user_ca ~/ssh-ca/host_ca
chmod 644 ~/ssh-ca/user_ca.pub ~/ssh-ca/host_ca.pub
ls -l ~/ssh-ca

Legt jetzt eine Sicherung der beiden privaten Schlüssel an einem zweiten Ort an. Ein verlorener CA-Schlüssel bedeutet, dass ihr auf jedem Server von Hand wieder auf authorized_keys zurückfallen müsst. Wer ohnehin mit Hardwareschlüsseln arbeitet, findet die Grundlagen dazu unter Server SSH Zugang mit YubiKey absichern.

Schritt 2: Den Servern beibringen, wem sie glauben

Kopiert den öffentlichen Teil der Benutzer-CA auf den Server. Nur diesen — der private Schlüssel hat auf dem Server nichts verloren:

scp ~/ssh-ca/user_ca.pub benutzer@server:/tmp/user_ca.pub
ssh benutzer@server
sudo mv /tmp/user_ca.pub /etc/ssh/user_ca.pub
sudo chown root:root /etc/ssh/user_ca.pub
sudo chmod 644 /etc/ssh/user_ca.pub

Dann eine Zeile in die Serverkonfiguration. Die Direktive dafür heisst TrustedUserCAKeys und ist in sshd_config(5) beschrieben als "a file containing public keys of certificate authorities that are trusted to sign user certificates for authentication":

sudo tee /etc/ssh/sshd_config.d/60-ssh-ca.conf >/dev/null <<'EOF'
TrustedUserCAKeys /etc/ssh/user_ca.pub
EOF

sudo sshd -t && sudo systemctl reload ssh

Der Aufruf sshd -t prüft die Konfiguration, ohne den Dienst anzufassen. Nehmt ihn euch zur Gewohnheit: Ein Tippfehler in sshd_config und ein beherzter Neustart sind die klassische Art, sich selbst auszusperren. Heisst die Unit auf eurem System sshd statt ssh, passt den Namen an. Existiert /etc/ssh/sshd_config.d/ nicht oder wird es nicht eingebunden, schreibt die Zeile direkt in /etc/ssh/sshd_config.

Wichtig: Diese Zeile ergänzt die Anmeldung, sie ersetzt sie nicht. Eure bestehenden Einträge in authorized_keys funktionieren unverändert weiter — und das soll bis zum Schluss dieser Anleitung auch so bleiben.

Schritt 3: Den ersten Benutzerschlüssel signieren

Zurück auf dem Rechner mit der CA. Ihr braucht dort den öffentlichen Schlüssel des Anwenders, den ihr ausstatten wollt — also die Datei id_ed25519.pub von seinem Arbeitsgerät. Signiert wird so:

ssh-keygen -s ~/ssh-ca/user_ca \
  -I "mario@laptop" \
  -n mario,deploy \
  -V +8w \
  -z 1001 \
  id_ed25519.pub

Die Schalter stehen in ssh-keygen(1). -s gibt den CA-Schlüssel an, mit dem unterschrieben wird. -I setzt die Kennung, die später in jeder Protokollzeile des Servers auftaucht — nehmt etwas, mit dem ihr Person und Gerät wiederfindet. -n nennt die Principals: "Multiple principals may be specified, separated by commas." -V ist die Gültigkeit, -z eine Seriennummer, die laut Handbuch dazu dient, "to distinguish this certificate from others from the same CA" — die braucht ihr spätestens beim Widerrufen.

Herausgekommen ist eine Datei id_ed25519-cert.pub. Schaut sie euch an, bevor ihr sie weitergebt:

ssh-keygen -L -f id_ed25519-cert.pub

Die Ausgabe zeigt Typ, Kennung, Seriennummer, Principals, Gültigkeitszeitraum und die enthaltenen Erweiterungen im Klartext — eure Kontrolle, dass wirklich das im Zertifikat steht, was ihr gemeint habt.

Die Zertifikatsdatei kommt nun neben den privaten Schlüssel auf dem Arbeitsgerät, also nach ~/.ssh/id_ed25519-cert.pub. Mehr ist nicht zu tun: Laut ssh_config(5) gilt, dass "if no certificates have explicitly been specified by CertificateFile, ssh(1) will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile." Wollt ihr das Zertifikat woanders ablegen, tragt den Pfad mit CertificateFile in ~/.ssh/config ein.

Der Test:

ssh -v mario@server 2>&1 | grep -i cert

Taucht dort eine Zeile mit ED25519-CERT auf und die Anmeldung gelingt, ist der Weg fertig. Behaltet die alte Sitzung offen, bis das sicher funktioniert.

Schritt 4: Principals sauber von Benutzernamen trennen

Bis hierher hat der Server eine stillschweigende Annahme gemacht. sshd_config(5) beschreibt sie bei AuthorizedPrincipalsFile: Der Standardwert ist "none, i.e. not to use a principals file", und dann gilt — "in this case, the username of the user must appear in a certificate's principals list for it to be accepted". Deshalb steht oben mario in der Principal-Liste.

Das skaliert schlecht: Ihr müsstet in jedes Zertifikat jeden Benutzernamen schreiben, unter dem sich jemand irgendwo anmelden können soll. Der bessere Weg ist eine Datei je Zielbenutzer, die sagt, welche Rollen dort hineindürfen:

sudo mkdir -p /etc/ssh/auth_principals
echo 'deploy' | sudo tee /etc/ssh/auth_principals/www-deploy
echo -e 'dba\nnotfall' | sudo tee /etc/ssh/auth_principals/postgres
sudo chown -R root:root /etc/ssh/auth_principals
sudo chmod 644 /etc/ssh/auth_principals/*

Und in der Serverkonfiguration:

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Das %u ist der Benutzername, unter dem die Anmeldung versucht wird. Laut sshd_config(5) sind an dieser Stelle die Token %%, %h, %U und %u erlaubt. Wer sich als www-deploy anmelden will, braucht ab jetzt ein Zertifikat mit dem Principal deploy — sein eigener Benutzername steht nirgends mehr im Zertifikat.

Das ist der eigentliche Gewinn der ganzen Übung. Ihr stellt ein Zertifikat auf eine Rolle aus und entscheidet danach auf jedem Server lokal, welche Rolle dort etwas darf. Wer die Rolle verliert, verliert sie überall gleichzeitig — ohne dass ihr einen einzigen Schlüssel suchen müsst. Wird die Zuordnung komplizierter, gibt es dafür noch AuthorizedPrincipalsCommand, ein Programm, das die erlaubten Principals zur Laufzeit ausrechnet.

Schritt 5: Kurze Gültigkeit statt langer Schlüssel

Ein Zertifikat läuft ab, ein öffentlicher Schlüssel nicht. Das ist der zweite grosse Unterschied, und er ist mehr wert als jede Widerrufsliste. Die Syntax von -V beschreibt ssh-keygen(1) so: "A validity interval may consist of a single time, indicating that the certificate is valid beginning now and expiring at that time, or may consist of two times separated by a colon to indicate an explicit time interval." Die Beispiele aus dem Handbuch:

• +52w1d — gültig ab jetzt für 52 Wochen und einen Tag.
• -4w:+4w — gültig von vor vier Wochen bis in vier Wochen.
• 20100101123000:20110101123000 — ein fester Zeitraum mit Datum und Uhrzeit.
• -1m:forever — gültig ab vor einer Minute und niemals ablaufend.

Die letzte Form solltet ihr nicht benutzen. Sie baut genau den Zustand nach, den ihr gerade loswerden wolltet. Für Personen sind wenige Wochen ein brauchbarer Wert, für automatische Zugänge wie ein Deployment-Konto eher Stunden. Das kleine Minus am Anfang, etwa -5m:+8w, ist kein Schönheitsfehler, sondern der Umgang mit ungenauen Uhren: Läuft die Uhr des Servers ein paar Minuten vor, wäre ein frisch ausgestelltes Zertifikat dort sonst noch nicht gültig.

Kurze Laufzeiten heissen regelmässiges Nachsignieren. Ein kleines Skript, das den öffentlichen Schlüssel neu signiert und die Zertifikatsdatei ablegt, lässt sich sauber über einen systemd-Timer statt eines Cronjobs auslösen — samt Benachrichtigung, wenn es einmal nicht klappt. Achtet dabei darauf, dass der CA-Schlüssel dafür nicht ungeschützt auf einem dauerhaft laufenden Rechner landet.

Schritt 6: Was das Zertifikat überhaupt erlauben darf

Ohne weitere Angaben stellt ssh-keygen ein Zertifikat mit den üblichen Erlaubnissen aus: Terminal, Portweiterleitung, Agent-Weiterleitung, X11 und ~/.ssh/rc. Für ein Zertifikat, das nur ein Backup abholen soll, ist das zu viel. Mit -O clear räumt ihr erst alles ab — laut Handbuch "Clear all enabled permissions. This is useful for clearing the default set of permissions so permissions may be added individually." — und gebt danach einzeln zurück, was gebraucht wird:

ssh-keygen -s ~/ssh-ca/user_ca \
  -I "backup-runner" \
  -n backup \
  -V +1d \
  -z 2001 \
  -O clear \
  -O force-command="/usr/local/bin/backup-pull" \
  -O source-address=10.0.0.0/24 \
  backup_key.pub

Dieses Zertifikat kann genau eine Sache. force-command ist in PROTOCOL.certkeys beschrieben als "a command that is executed (replacing any the user specified on the ssh command-line) whenever this key is used for authentication" — was der Aufrufer als Befehl mitschickt, ist damit egal. source-address ist eine "comma-separated list of source addresses from which this certificate is accepted for authentication. Addresses are specified in CIDR format". Und weil permit-pty nach dem clear fehlt, gibt es kein Terminal: "In the absence of this option PTY allocation will be disabled."

Beide Beschränkungen sind critical options: Ein Server, der sie nicht versteht, lehnt das Zertifikat ab, statt es durchzuwinken. Die Erlaubnisse permit-pty, permit-port-forwarding, permit-agent-forwarding, permit-user-rc und permit-X11-forwarding sind dagegen extensions und werden stillschweigend übergangen, wenn ein Server sie nicht kennt.

Schritt 7: Hostzertifikate und das Ende der known_hosts-Frage

Bis jetzt ging es darum, wie der Server euch erkennt. Die andere Richtung ist mindestens so wichtig und wird viel seltener gemacht. Jeder kennt die Frage beim ersten Verbindungsaufbau, ob der Fingerabdruck des Servers stimmt — und jeder kennt die ehrliche Antwort darauf: Nachgeprüft wird sie fast nie, bestätigt wird sie immer.

Ein Hostzertifikat schafft diese Frage ab. Signiert wird der öffentliche Hostschlüssel des Servers, den ihr euch vorher holt:

scp benutzer@server:/etc/ssh/ssh_host_ed25519_key.pub .

ssh-keygen -s ~/ssh-ca/host_ca \
  -I "web01" \
  -h \
  -n web01.example.ch,web01,10.0.0.11 \
  -V +52w \
  -z 3001 \
  ssh_host_ed25519_key.pub

Der Schalter -h ist der Unterschied: "When signing a key, create a host certificate instead of a user certificate." In die Principals gehört jeder Name, unter dem der Server angesprochen wird — voller Name, Kurzform und IP-Adresse. Wer das vergisst, wundert sich, warum die Verbindung über die IP wieder nachfragt.

Die entstandene Datei ssh_host_ed25519_key-cert.pub kommt zurück auf den Server, und dort wird sie bekannt gemacht. sshd_config(5) beschreibt HostCertificate als "a file containing a public host certificate. The certificate's public key must match a private host key already specified by HostKey.":

scp ssh_host_ed25519_key-cert.pub benutzer@server:/tmp/
ssh benutzer@server
sudo mv /tmp/ssh_host_ed25519_key-cert.pub /etc/ssh/
sudo chown root:root /etc/ssh/ssh_host_ed25519_key-cert.pub
sudo chmod 644 /etc/ssh/ssh_host_ed25519_key-cert.pub
echo 'HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub' \
  | sudo tee -a /etc/ssh/sshd_config.d/60-ssh-ca.conf
sudo sshd -t && sudo systemctl reload ssh

Bleibt die Client-Seite. Der öffentliche Host-CA-Schlüssel kommt in die known_hosts, aber mit einem Marker davor. sshd(8) beschreibt ihn im Abschnitt zum Dateiformat: @cert-authority dient dazu, "to indicate that the line contains a certification authority (CA) key".

{ printf '@cert-authority *.example.ch '; cat ~/ssh-ca/host_ca.pub; } \
  >> ~/.ssh/known_hosts

Ab jetzt gilt jeder Server unter *.example.ch als bekannt, sobald er ein gültiges Hostzertifikat vorzeigt — auch der, den ihr erst nächste Woche aufsetzt. Löscht die alten Einzeleinträge dieser Server aus der Datei, sonst prüft der Client weiterhin gegen den dort hinterlegten Schlüssel. Auf mehreren Geräten genügt es, diese eine Zeile zu verteilen oder sie systemweit in /etc/ssh/ssh_known_hosts abzulegen.

Schritt 8: Widerrufen, bevor ihr es braucht

Kurze Laufzeiten sind die beste Widerrufsliste, weil sie ohne Zutun wirken. Trotzdem braucht ihr einen Weg, ein noch gültiges Zertifikat sofort zu entwerten. OpenSSH kennt dafür Key Revocation Lists, und ssh-keygen(1) beschreibt sie so: "These binary files specify keys or certificates to be revoked using a compact format." Erzeugt wird eine solche Liste mit -k:

ssh-keygen -k -f revoked.krl id_ed25519-cert.pub
ssh-keygen -k -u -f revoked.krl weiteres-cert.pub
ssh-keygen -Q -f revoked.krl id_ed25519-cert.pub

Die erste Zeile legt die Liste an, die zweite ergänzt sie — zu -u sagt das Handbuch: "keys listed via the command line are added to the existing KRL rather than a new KRL being created". Die dritte prüft nach: -Q "will query an existing KRL, testing each key specified on the command line" und endet mit einem Rückgabewert ungleich null, wenn der Schlüssel gesperrt ist. Sperren geht auch ohne das Zertifikat in der Hand, nämlich über Kennung oder Seriennummer — beim Erzeugen einer KRL gibt -s dann "a path to a CA public key file used to revoke certificates directly by key ID or serial number" an.

Die Liste muss auf jeden Server und dort eingetragen werden. RevokedKeys nimmt beide Formate: "Keys may be specified as a text file, listing one public key per line, or as an OpenSSH Key Revocation List (KRL) as generated by ssh-keygen(1)."

echo 'RevokedKeys /etc/ssh/revoked.krl' \
  | sudo tee -a /etc/ssh/sshd_config.d/60-ssh-ca.conf
sudo sshd -t && sudo systemctl reload ssh

Zwei Stolperfallen. Erstens: Zeigt RevokedKeys auf eine Datei, die es nicht gibt, verweigert sshd die Anmeldung — legt die Datei also an, bevor ihr die Zeile setzt. Zweitens wirkt eine Widerrufsliste nur dort, wo sie liegt; der beim Verteilen vergessene Server akzeptiert das gesperrte Zertifikat weiter. Für die Gegenrichtung kennt die known_hosts den Marker @revoked, der laut sshd(8) anzeigt, "that the key contained on the line is revoked and must not ever be accepted".

Der Preis: was ihr euch mit einer CA einhandelt

Ihr tauscht ein verteiltes Problem gegen ein zentrales ein, und diese Gegenseite ist nicht klein. Der CA-Schlüssel ist ab sofort der wertvollste Gegenstand in eurer Infrastruktur: Wer ihn hat, hat alles — ohne dass irgendwo eine Datei verändert werden müsste, die euch auffiele. Bei authorized_keys hinterlässt ein Angreifer wenigstens Spuren.

Dazu kommen praktische Kanten. Zertifikate laufen ab, und sie tun das mit Vorliebe am Freitagabend. Verwaltungsoberflächen von Anbietern, Netzwerkgeräte und manche Backup-Ziele sprechen nur klassische Schlüssel; ihr braucht also weiterhin einen Rückfallweg, der ebenso gepflegt werden will. Und der ganze Aufbau hängt an synchronen Uhren.

Unterhalb von etwa drei Servern und zwei Geräten lohnt sich das schlicht nicht. Wer einen Heimserver betreibt, ist mit einem sauber gesetzten Schlüssel, abgeschalteter Passwortanmeldung und einer Absicherung wie CrowdSec besser bedient als mit einer eigenen Zertifizierungsstelle. Interessant wird es ab dem Punkt, an dem ihr anfangt, eine Tabelle darüber zu führen, welcher Schlüssel auf welchem Rechner liegt.

Bevor ihr die CA scharf schaltet

Diese Anleitung hat bewusst nichts abgeschaltet. Der letzte Schritt — authorized_keys leeren — kommt erst, wenn diese Punkte alle abgehakt sind:

• Eine zweite SSH-Sitzung zum Server ist offen und bleibt offen, bis alles geprüft ist. Sie ist eure Rückfahrkarte.
• Die Anmeldung mit Zertifikat funktioniert aus einer neuen Sitzung, nicht nur laut ssh -v.
• Der private CA-Schlüssel liegt gesichert an einem zweiten Ort, ist mit einer Passphrase geschützt und befindet sich nicht auf einem der abgesicherten Server.
• Die Datei aus RevokedKeys existiert tatsächlich, und ihr habt einmal geprüft, dass ein gesperrtes Zertifikat wirklich abgewiesen wird.
• Die Uhren von Server und Arbeitsgerät gehen synchron, und beim Signieren ist ein kleiner Vorlauf wie -5m gesetzt.
• Ihr wisst, wie ihr auf den Server kommt, wenn SSH gar nicht mehr geht — Konsole beim Anbieter, IPMI, Bildschirm und Tastatur. Und sshd -t läuft vor jedem reload fehlerfrei durch.
• Es ist notiert, welche Zertifikate mit welcher Seriennummer und Laufzeit ausgestellt wurden. Ohne diese Notiz ist gezieltes Widerrufen später Raten.

Fazit: Zertifikate lösen ein Verteilproblem, kein Vertrauensproblem

SSH-Zertifikate nehmen euch die Arbeit ab, die eigentliche Frage aber nicht. Ein Zugang muss nicht mehr an dreissig Stellen gepflegt und an dreissig Stellen wieder entfernt werden; er entsteht an einer und verschwindet von allein. Der Gewinn wächst mit der Zahl der Rechner und Personen.

Was sie nicht lösen, ist die Frage, wem ihr eigentlich vertraut. Die verschiebt sich nur — vom einzelnen Schlüssel auf den einen Schlüssel, der alle anderen unterschreibt. Ein Zertifikat ist eine Aussage, keine Prüfung: Es sagt, dass jemand mit dem CA-Schlüssel diesen Zugang gutgeheissen hat. Ob das eine gute Entscheidung war, steht nicht drin.

Genau deshalb ist die entscheidende Massnahme dieser Anleitung nicht der Signierbefehl, sondern der USB-Stick im Schrank. Alles andere ist Handwerk und in zwei Stunden erledigt. Wer die CA dagegen ohne Passphrase auf dem Rechner liegen lässt, von dem aus er ohnehin ständig arbeitet, hat sich die Mühe gespart — und mit ihr die Sicherheit.

Quellen und weiterführende Links

• ssh-keygen(1) — Abschnitte CERTIFICATES und KEY REVOCATION LISTS, alle Schalter zum Signieren und Widerrufen.
• sshd_config(5) — TrustedUserCAKeys, HostCertificate, AuthorizedPrincipalsFile, AuthorizedPrincipalsCommand, RevokedKeys, CASignatureAlgorithms.
• sshd(8) — Aufbau von authorized_keys und known_hosts samt der Marker @cert-authority und @revoked.
• ssh_config(5) — CertificateFile und das automatische Laden von -cert.pub neben IdentityFile.
• ssh(1) — Optionen des Clients, unter anderem -i und die Ausgabe von -v.
• OpenSSH 5.4 Release Notes vom 08.03.2010 — die Ankündigung der Zertifikatsunterstützung im Wortlaut.
• PROTOCOL.certkeys — die Formatbeschreibung, Begründung gegen X.509, Liste der critical options und extensions.
• OpenSSH-Projektseite — Quelltext, Release Notes und Sicherheitshinweise; aktuell ist dort OpenSSH 10.5 vom 11.08.2026 verzeichnet.
• Auf yourdevice.ch: Sicher per SSH einloggen, Server SSH Zugang mit YubiKey absichern, systemd-Timer statt Cronjob und Unterwegs sicher und stabil arbeiten mit SSHFS.

The post SSH-Zertifikate: eine eigene SSH-CA einrichten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was MTE technisch macht, warum GrapheneOS ohne diese Funktion keine Geräte offiziell unterstützt und weshalb ausgerechnet Qualcomm sie jahrelang nicht liefern konnte, haben wir in GrapheneOS ohne Google Pixel ausführlich erklärt. Dieser Beitrag setzt dort an und trägt den Stand vom 7. September nach.

Pixel 11 MTE: der Stand nach neun Tagen

Die Kurzfassung vorweg, weil sich die Lage dreimal gedreht hat und ihr sonst dem falschen Zwischenstand aufsitzt. Die Hardware des Pixel 11 beherrscht MTE — zumindest in einer Minimalvariante. Die Firmware gibt die Funktion inzwischen wieder frei. Das ausgelieferte Betriebssystem schaltet sie trotzdem nicht ein. Und Google sagt nicht, warum.

Das ist etwas anderes als „Google hat die Sicherheitsfunktion aus dem Chip gestrichen", und es ist deutlich mehr als eine Nuance: Von der Antwort hängt ab, ob GrapheneOS die Pixel-11-Reihe je unterstützen kann. Für alle, die ein Gerät mit dem Betriebssystem kaufen wollen — unser Einsteiger-Guide erklärt die Einrichtung Schritt für Schritt —, ist das die einzige Frage, die im Herbst 2026 zählt.

Was am 29. August gemeldet wurde

GrapheneOS veröffentlicht das meiste zuerst auf Mastodon, und die Ausgangsmeldung war unmissverständlich. Nach einer Woche Arbeit lag eine Teilportierung vor, abschliessen liess sie sich nicht. „Pixel 11 doesn't have MTE support. It's entirely gone." Kurz darauf die Feststellung, dass die Pixel-11-Reihe die eigenen Sicherheitsanforderungen nicht zu erfüllen scheine.

Ganz nebenbei enthielt derselbe Faden auch das Gegenteil einer Abrechnung. Das Pixel 11 bringe durchaus Verbesserungen mit, namentlich einen quantensicheren Verified Boot per ML-DSA, den Ersatz von Samsungs Shannon-IMS durch AOSP-IMS und einen Titan M3, der den Schutz gegen Datenextraktion deutlich verbessern sollte. Nur nütze das wenig, wenn gleichzeitig MTE wegfällt.

Warum MTE für GrapheneOS kein Extra ist

Die ARM Memory Tagging Extension versieht Speicherbereiche mit einer Markierung und prüft bei jedem Zugriff, ob die Markierung des Zeigers dazu passt. Ganze Fehlerklassen — Use-after-free, Pufferüberläufe — fliegen damit zur Laufzeit auf, statt zur Angriffsfläche zu werden. Das ist im Bestandsartikel ausgeführt und wird hier nicht wiederholt.

Entscheidend für die aktuelle Lage ist der Umfang der Nutzung. GrapheneOS setzt MTE im gesamten Basissystem ein, einschliesslich Kernel und sämtlicher Standardprozesse; nur für einige gerätespezifische Prozesse ist es vorübergehend abgeschaltet. Ein Gerät ohne MTE ist für dieses Projekt also nicht ein Gerät mit einem fehlenden Häkchen, sondern eines, auf dem die zentrale Schutzschicht des Systems ersatzlos entfällt.

Ein Ersatz wäre technisch denkbar und praktisch unattraktiv: HWASan käme mit rund doppeltem CPU-Aufwand und 25 Prozent mehr Speicherbedarf und liesse sich sinnvoll nur auf den Kernel und einige wichtige Teile des Systems begrenzen. Zur Erinnerung: Das Pixel 8 kam im Oktober 2023 mit Hardware-MTE, GrapheneOS hat es noch im selben Monat quer durch das System eingesetzt — Android und das Pixel-System selbst haben es nie standardmässig aktiviert. Wer die Funktion überhaupt benutzt, ist eine sehr kurze Liste, und Google steht nicht darauf.

Ein Dollar pro Telefon: die Rechnung stammt von GrapheneOS, nicht von Google

An dieser Stelle ist Vorsicht geboten, denn hier vermischen viele Berichte Zuschreibung und Beleg. Die These, Google habe an der Chipfläche gespart, ist eine Vermutung von GrapheneOS — und das Projekt kennzeichnet sie selbst als solche. Rund vier Prozent der Cache-Fläche liessen sich einsparen; bei einem SoC-Preis von 150 Dollar und einem Cache-Anteil von einem Viertel ergäbe das etwa 1,50 Dollar pro Telefon — „that's not a well informed estimate of the price of MTE but it does have a price". Einen Tag später präzisierte das Projekt: Ohne dynamische Zuteilung brauche MTE einen um 3,125 Prozent grösseren CPU-Cache und einen aufwendigeren Cache-Controller, was auf etwa einen Dollar je Gerät hinauslaufe.

Eine Stellungnahme von Google zu dieser Rechnung gibt es nicht. Die Schätzung als Googles Begründung auszugeben, wäre deshalb falsch — und genau das ist in der Berichterstattung mehrfach passiert.

Belegt ist dagegen der Rahmen. MTE ist in ARMv9 optional und nicht Pflicht; die meisten ARMv9-Umsetzungen haben es nicht. Qualcomm hat es erst im Snapdragon 8 Elite Gen 5, und im eine Stufe darunter liegenden Snapdragon 8 Gen 5 ist es wegen Errata funktionslos. Und GrapheneOS hat nach eigener Darstellung bereits 2024 gehört, dass Google MTE im Zuge des Umstiegs auf eigene CPU-Kerne fallenlassen wollte — beim Tensor G5 des Pixel 10 geschah das nicht, und der Tensor G6 nutzt noch gar keine eigenen Kerne. Notebookcheck hat dazu geleakte interne Unterlagen ausgewertet, in denen „MTE support" in einer Prioritätenliste zur Cache-Architektur rot durchgestrichen ist; wann der Strich gesetzt wurde, geht daraus nicht hervor.

Der Rückzieher: die Firmware-Unterstützung ist wieder da

Am 1. September kam die Wende, und sie kam aus einer Beta. Android 17 QPR2 Beta 4 erschien am 28. August, die Abbilder für die Pixel-11-Reihe wurden nach Darstellung von GrapheneOS aber erst rund drei Tage später nachgeschoben. 9to5Google nennt für den Beitritt der Pixel-11-Modelle zum Beta-Programm den 1. September und den Build CP41.260814.003.C2.

Das Ergebnis der Prüfung: „It still has at least bare minimum support for MTE at a hardware level." Die Vermutung des Projekts lautet seither, dass Google die Beschleunigung im CPU-Cache entfernt und damit die Leistung ruiniert habe, weshalb die Funktion in der Firmware komplett abgeschaltet worden sei. In QPR2 Beta 4 ist die Firmware-Unterstützung wieder vorhanden, das Betriebssystem lässt MTE aber weiterhin aus, und die Firmware übergibt dem Kernel bedingungslos den Parameter arm64.nomte. Von Hand geht es trotzdem: Der Tag-Speicher lässt sich über fastboot oem mte on reservieren, danach braucht es einen Kernel, der arm64.nomte ignoriert.

Und heute, am 7. September, hat sich auch die letzte offene Frage in eine unerwartete Richtung bewegt. Die Sorge lautete ja, MTE könnte auf dem Pixel 11 zwar existieren, aber unbrauchbar langsam sein. GrapheneOS schreibt dazu: Die Funktion sei über den Fastboot-Modus einschaltbar und dann im Serienbetriebssystem per ADB nutzbar, sie stehe aber weder im Advanced Protection Mode noch in den Entwickleroptionen zur Verfügung. „It isn't clear why it isn't enabled for use in the stock OS yet. It appears to work fine and performs fine."

Damit ist von der Ausgangsdiagnose nach neun Tagen wenig übrig. Die Hardware kann es, die Firmware kann es, es funktioniert, und es ist schnell genug. Abgeschaltet ist es trotzdem.

Was Google dazu sagt

Nichts. GrapheneOS hat nach eigener Angabe schon vor der ersten Meldung mehrere Leute bei Google angeschrieben und keine Antwort erhalten; bis heute weiss das Projekt nicht, ob es ernsthafte CPU-Errata gibt oder ob die Funktion schlicht schlecht lief. Als strukturelle Erklärung nennt GrapheneOS, dass Google auf seine Anfragen zunehmend schweige, seit im Juni 2025 die Pixel-Unterstützung mit Android 16 aus AOSP herausgefallen ist — ein Vorgang, den wir seinerzeit in Google erschwert Custom-ROMs für Pixel-Geräte beschrieben haben und der sich in der Suche nach einem zweiten Hardware-Partner fortsetzte.

Eine Auskunft gab es dann doch, sie war nur nichts wert. Ein Nutzer berichtete, Google habe ihm bestätigt, MTE werde mit dem September-Update aktiviert. GrapheneOS prüfte nach: Gefragt worden war ein Support-Mitarbeiter, der nicht bei Google arbeitet und noch nie von MTE gehört hatte — „the support agent clearly used an LLM to fabricate something to close the ticket". Ein Konzern, der eine Speicherschutzfunktion nicht kommentiert, aber ein Sprachmodell eine erfinden lässt, damit ein Ticket zugeht: Das ist der Zustand der Kundenkommunikation im Jahr 2026, in einem Satz.

Worauf ihr achten solltet

Für die Kaufentscheidung ist die Lage trotz aller Drehungen ziemlich klar, und sie hat sich seit dem 31. August nicht verbessert.

• Ein Pixel 11 ist heute kein GrapheneOS-Gerät. Es steht nicht auf der Liste der unterstützten Geräte, und das Projekt hat sich noch nicht entschieden. Der Stand von heute: Der Grossteil der Portierung ist fertig, weitergearbeitet wird nach Abschluss von Android 17 QPR1 — offiziell unterstützt wird nur, was nachweislich funktioniert.
• Wer bereits gekauft hat, prüft die Rückgabefrist. GrapheneOS verweist selbst auf die 15-tägige Rückgabemöglichkeit ohne Begründung und die Empfehlung, stattdessen zum Pixel 10 zu greifen. Ob diese Frist auch für euren Händler in der Schweiz gilt, steht in dessen Bedingungen und nicht bei Google.
• Das Pixel 11 ist nicht generell unsicher. Diese Verkürzung geistert durch die Kommentarspalten. GrapheneOS ordnet es ausdrücklich über Pixel 6 und 7 ein und weit über Geräte ohne Secure Element und ohne verlässliche Firmware-Updates — ein Rückschritt ist es gegenüber Pixel 8, 9 und 10.
• Achtet auf die Nebenwirkungen. Unabhängig von MTE nennt GrapheneOS eine gegenüber dem Pixel 10 leicht schwächere GPU, rund 15 Prozent mehr CPU-Leistung und 2 GB weniger Arbeitsspeicher bei den Basis-Pro-Modellen. Für den Aufpreis einer neuen Generation ist das eine dünne Bilanz.
• Bastellösungen taugen nicht als Kaufgrund. Dass sich MTE per fastboot und ADB einschalten lässt, ist ein Befund für Entwickler, kein Produktmerkmal. Solange es weder im Advanced Protection Mode noch in den Entwickleroptionen steht, ist es für den Alltag nicht vorhanden.

Fazit: Ein gesparter Dollar kostet Google drei Gerätegenerationen Vorsprung

Die Pixel-Reihe hatte genau ein Alleinstellungsmerkmal, das über Kameravergleiche hinausging: Sie war die einzige Android-Hardware, auf der ein kompromissloses Sicherheitssystem überhaupt laufen konnte. Genau deshalb musste Motorola MTE zusagen, bevor GrapheneOS eine Partnerschaft einging. Wer diese Anforderung an einen fremden Hersteller stellt, kann sie beim eigenen Lieferanten nicht fallenlassen, ohne die eigenen Standards zu entwerten — und genau so hat das Projekt es selbst formuliert.

Bemerkenswert ist deshalb weniger die technische Panne als die Reihenfolge. Zuerst wird eine Funktion so weit abgeräumt, dass niemand sie ausprobieren kann. Dann kommt sie in einer Beta leise zurück. Dann stellt sich heraus, dass sie funktioniert und schnell genug ist. Und die einzige Stelle, die sagen könnte, was das alles soll, sagt gar nichts. Es ist dieselbe Kommunikationsverweigerung, die uns schon bei der Entwickler-Verifizierung und bei der Frage nach Googles Zugriff auf Pixel-Geräte begegnet ist.

Bis das geklärt ist, gilt die schlichteste aller Empfehlungen: Kauft das Vorgängermodell. Und wenn Google die drei Zeilen Firmware-Konfiguration doch noch freigibt, berichten wir darüber — dann hoffentlich mit einer Antwort von Google statt einer vom Sprachmodell eines Callcenters.

Quellen und weiterführende Links

• GrapheneOS, 29.08.2026: Teilportierung auf die Pixel-11-Reihe, MTE fehlt in Software, Firmware und wahrscheinlich Hardware
• GrapheneOS, 29.08.2026: „Pixel 11 doesn't have MTE support. It's entirely gone."
• GrapheneOS, 29.08.2026: MTE wird im gesamten Basissystem einschliesslich Kernel eingesetzt
• GrapheneOS, 29.08.2026: Pixel 8 mit Hardware-MTE seit Oktober 2023, Android nutzt es nie standardmässig
• GrapheneOS, 29.08.2026: Verbesserungen des Pixel 11 — ML-DSA, AOSP-IMS, Titan M3
• GrapheneOS, 30.08.2026: Einordnung gegenüber Pixel 6, Pixel 7 und Geräten ohne Secure Element
• GrapheneOS, 30.08.2026: Schätzung von rund 1,50 Dollar je Telefon, ausdrücklich als grobe Rechnung gekennzeichnet
• GrapheneOS, 30.08.2026: MTE ist in ARMv9 optional; Qualcomm erst ab Snapdragon 8 Elite Gen 5
• GrapheneOS, 30.08.2026: 3,125 Prozent mehr Cache, aufwendigerer Cache-Controller, rund ein Dollar je Gerät
• GrapheneOS, 31.08.2026: HWASan als möglicher Teilersatz, rund doppelter CPU-Aufwand
• GrapheneOS, 31.08.2026: Die angebliche Google-Bestätigung stammt von einem externen Support-Mitarbeiter
• GrapheneOS, 31.08.2026: Hinweis auf die 15-tägige Rückgabefrist und die Empfehlung zum Pixel 10
• GrapheneOS, 31.08.2026: GPU, CPU-Leistung und Arbeitsspeicher im Vergleich zur Pixel-10-Reihe
• GrapheneOS, 01.09.2026: Hinweis aus dem Jahr 2024 auf den geplanten Wegfall von MTE bei eigenen CPU-Kernen
• GrapheneOS, 01.09.2026: Mindestunterstützung für MTE auf Hardware-Ebene vorhanden
• GrapheneOS, 01.09.2026: QPR2 Beta 4 vom 28.08., arm64.nomte wird bedingungslos übergeben
• GrapheneOS, 01.09.2026: Aktivierung über fastboot oem mte on und einen eigenen Kernel
• GrapheneOS, 01.09.2026: Anfragen an Google blieben unbeantwortet
• GrapheneOS, 01.09.2026: Google schweigt seit dem Wegfall der Pixel-Unterstützung in AOSP im Juni 2025
• GrapheneOS, 07.09.2026: MTE über Fastboot und ADB nutzbar, „appears to work fine and performs fine"
• GrapheneOS, 07.09.2026: Portierung weitgehend fertig, Fortsetzung nach Android 17 QPR1
• Android Developers: Android 17 QPR2 Beta
• Android Open Source Project: ARM Memory Tagging Extension
• 9to5Google, 01.09.2026: Pixel-11-Reihe im Beta-Programm, Build CP41.260814.003.C2
• Notebookcheck: Geleakte Unterlagen zur Cache-Architektur des Tensor G6
• GrapheneOS: Projektseite mit der Liste der unterstützten Geräte

The post Pixel 11 MTE: Die Hardware kann es, Google schweigt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Reaktionen waren erwartbar. „Brüssel greift nach euren Ersparnissen", „Zugriff auf euer Konto", „Enteignung durch die Hintertür". Wir haben uns die Vorschläge angesehen, die hinter dem Begriff tatsächlich liegen — und die Antwort ist unbequem für beide Seiten. Niemand nimmt euch etwas weg. Es ist auch gar nicht nötig. Genau das ist der interessante Teil, und er ist derselbe strukturelle Vorgang, den wir vor einer Woche schon bei der Zweigstellenpflicht für Drittstaatsbanken beschrieben haben: eine Regel, die euch gar nicht adressiert, ändert trotzdem, was euch offensteht.

Spar- und Investitionsunion: was tatsächlich auf dem Tisch liegt

Die Spar- und Investitionsunion ist kein neuer Einfall vom August 2026. Die Kommission hat ihre Strategie am 19. März 2025 vorgelegt. Sie ist der Nachfolger dessen, was jahrelang Kapitalmarktunion hiess und wenig bewegt hat. Der Befund darin: Rund 70 Prozent der privaten Ersparnisse in der EU liegen als Bankeinlage, im Gegenwert von etwa zehn Billionen Euro.

Der Rat gliedert das Vorhaben in vier Arbeitsstränge: Bürger und Ersparnisse, Investitionen und Finanzierung, Integration und Skalierung der Märkte, sowie wirksame Aufsicht im Binnenmarkt. Das klingt nach einem Behördenorganigramm und ist auch eines. Wichtiger als die Gliederung ist, welche Rechtsakte darunter tatsächlich liegen. Es sind, Stand heute, im Wesentlichen vier: die Verbriefungsreform vom Juni 2025, eine Empfehlung zu Sparkonten vom September 2025, ein Vorschlag zur europäischen Privatrente vom November 2025 und ein Paket zu Marktintegration und Aufsicht vom Dezember 2025. Dazu kam am 17. Juli 2026 eine Mitteilung zur Wettbewerbsfähigkeit des Bankensektors. Nachzulesen ist die Liste auf der Themenseite der Generaldirektion Finanzstabilität.

In keinem dieser Rechtsakte steht etwas, das einen Sparer zu irgendetwas verpflichtet. Das ist keine Beruhigungsformel, sondern der Befund nach Durchsicht der Primärquellen. Wer daraus eine Zwangsabgabe macht, liegt schlicht falsch — und liefert dabei genau die Munition, mit der sich die berechtigte Kritik anschliessend als Verschwörungserzählung abtun lässt.

Verbriefung: der eigentliche Hebel sitzt bei den Banken

Das Herzstück ist die Verbriefungsreform, die die Kommission am 17. Juni 2025 vorgeschlagen hat. Verbriefung heisst: Eine Bank bündelt Kredite — Firmenkredite, Hypotheken, Leasingforderungen — zu einem Paket, zerlegt dieses Paket in Tranchen unterschiedlichen Risikos und verkauft die Tranchen an Investoren. Das Kreditrisiko wandert aus der Bankbilanz heraus. Dadurch wird Eigenkapital frei, und mit diesem Eigenkapital kann die Bank neue Kredite vergeben.

Geändert werden sollen dafür gleich vier Regelwerke: die Verbriefungsverordnung selbst, die Kapitaladäquanzverordnung CRR, die Liquiditätsdeckungsverordnung und Solvency II für Versicherer. Konkret werden die Sorgfaltspflichten der Investoren „einfacher, verhältnismässiger und stärker prinzipienbasiert", die Zahl der Meldefelder soll um mindestens 35 Prozent sinken, und die Eigenkapitalanforderungen für vorrangige Verbriefungstranchen sollen um etwa ein Drittel fallen. Bei Portfolios aus KMU-Krediten dürfen künftig bis zu 70 Prozent eines Pools als homogen gelten, was die Bündelung erleichtert.

Das ist der Punkt, an dem die Zahl aus Paris herkommt. „Together, these measures could unlock up to EUR 470 billion in additional investment", sagte von der Leyen — bis zu 470 Milliarden Euro zusätzliche Investitionen, und zwar aus der Summe von Verbriefung, Anlagevorschriften für Banken und Versicherer sowie Marktintegration und Aufsicht. Es ist eine Schätzung der Kommission zur Wirkung ihrer eigenen Vorschläge, keine gemessene Grösse. Die Kommission selbst schreibt zur Frage, wie viel zusätzliche Kreditvergabe daraus wird, nüchtern, das hänge von vielen Faktoren ab.

Wer aufmerksam liest, sieht hier bereits, dass das Ersparte des Einzelnen in diesem Mechanismus gar nicht vorkommt. Adressat ist die Bank. Sie entscheidet, ob sie verbrieft. Adressat sind Versicherer und Fonds, die die Tranchen kaufen sollen. Der Kontoinhaber taucht in der ganzen Kette an genau einer Stelle auf: als jemand, dessen Einlage die Bank ohnehin schon weiterverliehen hat.

Zehn Billionen, die niemand herumliegen lässt

Damit sind wir beim schwächsten Satz der ganzen Rede. Ersparnisse auf einem Bankkonto liegen nicht brach. Sie liegen dort überhaupt nicht. Wer Geld auf ein Konto legt, gibt der Bank einen Kredit; die Bank verleiht ihn weiter, in aller Regel noch vor dem Frühstück. Genau darauf beruht die gesamte Verbriefungsreform: Sie will Bankbilanzen entlasten, damit Banken mehr Kredite vergeben können. Beides zugleich geht nicht: behaupten, das Geld liege still, und ein Instrument vorschlagen, dessen ganzer Zweck darin besteht, die bereits vergebenen Kredite weiterzureichen.

Was tatsächlich gemeint ist, ist etwas anderes und weniger griffig: Europäische Haushalte finanzieren Unternehmen überwiegend indirekt über Bankkredite und kaum direkt über Eigenkapital. Wer Wagniskapital braucht, findet in Europa weniger davon als in den USA. Das ist ein reales Problem und der Grund, warum der zweite Satz aus Paris deutlich besser sitzt als der erste: „And a large share of Europe's savings is invested outside our continent." Ein grosser Teil europäischer Ersparnisse wird ausserhalb Europas angelegt. Das stimmt, und es ist ein Befund über Renditeerwartungen, nicht über Faulheit.

Der Unterschied ist nicht sprachliche Feinarbeit. „Brachliegendes Geld" legt nahe, es müsse aktiviert werden — notfalls von aussen. „Geld, das woanders investiert wird" legt nahe, Europa müsse attraktiver werden. Das sind zwei völlig verschiedene politische Programme, und die Rede verwendet beide Bilder in vier Sätzen nacheinander.

Das Sparkonto, das die EU empfiehlt und nicht vorschreibt

Der einzige Teil der Spar- und Investitionsunion, der sich überhaupt an Privatpersonen richtet, ist das sogenannte Spar- und Investitionskonto. Die Kommission hat dazu am 30. September 2025 einen Vorschlag vorgelegt — und zwar in Form einer Empfehlung. Nicht als Verordnung, nicht als Richtlinie. Die Kommission „empfiehlt den Mitgliedstaaten, solche Konten einzuführen, wo es sie noch nicht gibt, und bestehende Modelle zu verbessern".

Eine Empfehlung ist das schwächste Instrument, das das Unionsrecht kennt. Sie ist rechtlich unverbindlich, ungefähr so zwingend wie ein Hinweisschild im Treppenhaus. Inhaltlich geht es um Konten bei Banken und Wertpapierfirmen, über die Privatanleger einfach in Aktien, Anleihen und Fonds investieren können, mit einer einheitlichen Nutzerführung, der Möglichkeit mehrerer Konten bei verschiedenen Anbietern — und, das ist der eigentliche Hebel, mit steuerlichen Anreizen. Steuervorteile seien „entscheidend", schreibt die Kommission. Über die entscheiden allerdings die Mitgliedstaaten, nicht Brüssel.

Auch das deutsche Bundesfinanzministerium beschreibt den eigenen Beitrag in seinem Monatsbericht vom Oktober 2025 ausdrücklich als Arbeit an Rahmenbedingungen und Anreizen: bessere Bedingungen für Start-ups, Bürokratieabbau, Stärkung der Nachfrageseite am Kapitalmarkt, dazu die Initiative „Finance Europe" als „freiwilliger Rahmen, den die Finanzindustrie durch geeignete Investmentlösungen ausfüllen soll". Von Verpflichtungen für Sparer steht dort kein Wort. Wer eine Zwangsanleihe erwartet hat, wird enttäuscht — und sollte den Text trotzdem lesen, denn Anreize sind wirksamer als Gebote und werden seltener beklagt.

Zwischenfazit an dieser Stelle: Von den vier Strängen der Spar- und Investitionsunion adressiert genau einer den Bürger, und der tut es mit dem unverbindlichsten Werkzeug im Schrank. Alles, was rechtlich Zähne hat, richtet sich an Banken, Versicherer, Fonds und Aufsichtsbehörden. Wer nach dem Zwang sucht, wird ihn nicht finden. Wer deshalb aufhört zu lesen, verpasst die Verschiebung.

Der Satz, der aufhorchen lässt, ist ein anderer

In derselben Passage der Pariser Rede steht ein Satz, der in den Empörungsmeldungen nicht vorkam, obwohl er der politisch bemerkenswerteste ist: „We now need to reach an agreement, before the end of the year, ideally with all 27 Member States. But if that doesn't work, if necessary we will do it with those that are ready."

Idealerweise mit allen 27, und wenn das nicht geht, eben mit denen, die bereit sind. Das ist die offene Ankündigung, ein Kernprojekt des Binnenmarkts notfalls in einer Teilmenge der Mitgliedstaaten umzusetzen. Bei einem Kapitalmarktvorhaben ist das keine Kleinigkeit: Ein Binnenmarkt, der für zwölf Länder anders funktioniert als für fünfzehn, ist ein Binnenmarkt mit Naht. Für Anleger heisst das im Zweifel, dass steuerliche Behandlung, Aufsicht und Produktangebot je nach Wohnsitz auseinanderlaufen — genau das, was die Spar- und Investitionsunion eigentlich beseitigen wollte.

Dass der Zeitdruck real ist, lässt sich am Verfahrensstand ablesen. Der Rat hat seine Position zur Verbriefungsreform Ende 2025 festgelegt, der Wirtschafts- und Währungsausschuss des Parlaments die seine am 6. Mai 2026; die Trilogverhandlungen werden für die zweite Jahreshälfte 2026 erwartet. „Vor Jahresende" ist also kein rhetorischer Schwung, sondern der Terminplan.

Der Haushalt, der im selben Atemzug genannt wird

Von der Leyen verband das Thema in Paris mit dem nächsten EU-Haushalt: „With over EUR 450 billion from the European Competitiveness Fund and the Horizon Europe programme, we will support the entire chain." Gemeint ist der Vorschlag für den mehrjährigen Finanzrahmen 2028 bis 2034, den die Kommission am 16. Juli 2025 vorgelegt hat: knapp zwei Billionen Euro für sieben Jahre, 1,26 Prozent des europäischen Bruttonationaleinkommens, darin 409 Milliarden für den Europäischen Fonds für Wettbewerbsfähigkeit und 175 Milliarden für Horizont Europa.

Wer nachrechnet, kommt auf 584 Milliarden und nicht auf „über 450". Die Differenz erklärt sich vermutlich daraus, dass aus dem Wettbewerbsfähigkeitsfonds 131 Milliarden für Verteidigung und Weltraum vorgesehen sind — 584 minus 131 ergibt 453. Ausdrücklich gesagt hat das niemand; es ist unsere Rechnung, nicht die der Kommission, und wer sie nicht tragen will, lässt sie weg.

Unstrittig ist dagegen, dass dieser Haushalt derzeit alles andere als beschlossen ist. Sechs Nettozahler — Deutschland, Österreich, Dänemark, Finnland, die Niederlande und Schweden — fordern Kürzungen um mehrere hundert Milliarden Euro und lehnen neue gemeinsame Schulden ab; die taz beschrieb den Vorstoss am 27. August 2026 als „Gipfel der Geizigen", ein Etikett, gegen das sich die Beteiligten wehren. Das ist der Zusammenhang, der die Rede erklärt: Wenn öffentliches Geld knapp verhandelt wird, wird privates Geld interessant. Von der Leyen sagt das in Paris sogar offen — nicht alles lasse sich aus der öffentlichen Kasse finanzieren. Wer die Haushaltsdebatte für ein Randthema hält, dem sei unser Beitrag „Warum die EU sterben muss, damit Europa leben kann" empfohlen; dort stehen die Zahlen zum europäischen Wachstum, die diesen Streit überhaupt erst erzeugen.

Wo der digitale Euro ins Bild kommt — und wo nicht

Jetzt zu der Frage, die dieses Thema für diesen Blog überhaupt interessant macht. Sie lautet nicht: Steckt der digitale Euro hinter der Spar- und Investitionsunion? Dafür gibt es keinerlei Beleg, und wer es behauptet, muss es belegen. Es sind zwei getrennte Vorhaben mit getrennten Rechtsgrundlagen, getrennten Zeitplänen und getrennten Zuständigkeiten: das eine bei der Kommission und den Finanzministerien, das andere bei der Europäischen Zentralbank. Die Frage lautet: Was wäre, wenn beide kämen?

Zur Erinnerung, ausführlich steht das in unserem Beitrag „Digitaler Euro: ein Versprechen ist kein Protokoll": Der digitale Euro ist als direkte Verbindlichkeit der Zentralbank angelegt, mit einer Haltegrenze, die nicht im Gesetz steht, sondern von der Kommission auf Empfehlung der EZB festgelegt und mindestens alle zwei Jahre überprüft werden soll. Bedingte Zahlungen sind technisch vorgesehen, programmierbares Geld soll untersagt sein. Am Stand hat sich seither wenig getan: Der jüngste Vorgang auf der Projektseite der EZB ist die Rulebook-Fassung 0.91 vom Juli 2026, geprüft am 5. September 2026.

Und hier liegt der Punkt, der sich ohne jede Spekulation formulieren lässt: Eine Haltegrenze ist bereits ein Steuerungsinstrument für private Ersparnisse. Sie legt fest, wie viel Geld ein Bürger in der sichersten verfügbaren Form halten darf. Alles darüber muss anderswohin — auf ein Bankkonto, in einen Fonds, in Wertpapiere. Das ist keine Verschwörung, das ist der erklärte Zweck: Die Haltegrenze soll verhindern, dass Einlagen aus den Geschäftsbanken abfliessen. Aber es ist eben auch eine Zahl, die per Rechtsakt festgelegt und alle zwei Jahre neu bestimmt wird, und die entscheidet, wie viel Erspartes stillstehen darf.

Der Gedanke des Betreibers dieses Blogs, den wir hier ausdrücklich als Gedankenexperiment und nicht als Befund führen, geht einen Schritt weiter: Wäre Geld eines Tages vollständig digital und in der Ausgabe zentralisiert, dann bräuchte es für eine Lenkung privater Ersparnisse weder eine Verbriefungsverordnung noch ein Steuerprivileg noch eine Empfehlung an die Mitgliedstaaten. Es bräuchte einen Parameter. Was heute vier Rechtsakte, zwei Gesetzgebungsorgane und einen Trilog kostet, wäre dann eine Einstellung.

Zwei Dinge sind dazu ehrlicherweise zu sagen. Erstens ist genau dieser Fall nicht geplant: Der Verordnungsentwurf zum digitalen Euro sieht ihn ausdrücklich als Ergänzung zum Bargeld vor, nicht als dessen Ersatz. Zweitens gilt aber auch, was wir zum digitalen Euro schon geschrieben haben — der Schutz besteht aus Paragrafen, nicht aus Physik. Bargeld verhindert Lenkung technisch. Ein digitaler Euro verhindert sie durch einen Satz im Rechtsakt, und wie belastbar solche Sätze über Jahre sind, kann jeder selbst einschätzen, der die Chatkontrolle über die letzten drei Jahre verfolgt hat.

Die Gegenposition, und warum sie zur Hälfte trägt

Die stärkste Erwiderung auf alles bisher Gesagte lautet: Ihr beschreibt ein Problem, das es nicht gibt. Europäische Haushalte legen zu wenig in Eigenkapital an, europäische Unternehmen finden zu wenig Wagniskapital, europäische Gründer gehen nach Amerika. Ein integrierter Kapitalmarkt mit einfachen, steuerlich vernünftigen Anlagekonten nützt genau den Leuten, die sich heute mit dem Zins auf dem Sparkonto abfinden. Wer das bekämpft, verteidigt den Status quo, und der Status quo ist teuer.

Diese Position ist gut, und sie trägt bis zur Hälfte. Ein einfacheres, billigeres, europaweit vergleichbares Anlagekonto wäre ein Fortschritt. Auch dass Verbriefung nicht per se Teufelszeug ist, sondern ein Standardinstrument, das in Europa nach 2008 überreguliert wurde, lässt sich vertreten.

Wo sie aufhört zu tragen, ist die Risikoseite. Verbriefung war 2008 nicht deshalb ein Problem, weil es sie gab, sondern weil niemand mehr wusste, was in den Paketen steckte und wer das Risiko am Ende trug. Die aktuelle Reform senkt Sorgfaltspflichten, kürzt Meldefelder um mindestens 35 Prozent und reduziert Eigenkapitalanforderungen für vorrangige Tranchen um rund ein Drittel. Jede einzelne dieser Massnahmen ist für sich begründbar. Zusammen ergeben sie: weniger Prüfung, weniger Transparenz, weniger Puffer. Wer das für risikolos hält, hat eine bemerkenswert kurze Erinnerung an das letzte Mal, als der Kontinent einen Kreditmarkt entfesselt hat.

Und ein zweiter Punkt: Die Bereitschaft, das Vorhaben notfalls nur mit „denen, die bereit sind" umzusetzen, ist bei einem Projekt, das ausdrücklich Marktfragmentierung beseitigen soll, ein Widerspruch, für den bisher niemand eine Auflösung angeboten hat.

Das Muster, das sich hier wiederholt

Wir haben in den letzten Wochen dreimal denselben Bauplan beschrieben, ohne ihn zu suchen. Bei der Plattformregulierung setzt der Gesetzgeber am Torwächter an, nicht am Nutzer. Bei CRD VI an der Bank, nicht am Kontoinhaber. Bei der Spar- und Investitionsunion an Bilanzregeln, Steuerrecht und Aufsicht, nicht am Sparer. Der Adressat trägt die Pflicht, der Bürger trägt die Folge, und in keinem Fall gibt es ein Verbot, gegen das sich klagen liesse.

Das ist keine Bosheit, es ist einfach die wirksamere Bauart. Ein Gebot an vierhundert Millionen Menschen ist unkontrollierbar. Eine geänderte Eigenkapitalanforderung für ein paar tausend beaufsichtigte Institute wirkt am nächsten Bilanzstichtag. Nur gehört die Debatte dann auch an die richtige Stelle — und nicht zu der Frage, ob jemand ans Sparbuch will.

Was noch offen ist

Eine Handlungsliste wäre an dieser Stelle unehrlich. Gegen einen Trilog über die Verbriefungsverordnung richtet ein einzelner Sparer nichts aus, und „legt euer Geld anders an" ist keine politische Antwort, sondern eine Anlageberatung, die wir nicht geben. Was wir stattdessen anbieten können, ist die Liste der Fragen, die derzeit unbeantwortet sind und an denen sich in den nächsten Monaten ablesen lässt, wohin das läuft.

• Kommt die Einigung vor Jahresende, und mit wie vielen Mitgliedstaaten? Der Satz „mit denen, die bereit sind" ist gefallen. Ob er eine Verhandlungsdrohung war oder ein Plan, entscheidet sich im Trilog.
• Wie weit werden die Sorgfaltspflichten am Ende tatsächlich gesenkt? Der Ausschussbeschluss des Parlaments vom 6. Mai 2026 hat den ursprünglichen Berichtsentwurf verändert; wie der Kompromiss aussieht, ist bis zum Abschluss offen.
• Welche Mitgliedstaaten folgen der Sparkonten-Empfehlung, und mit welchen Steuervorteilen? Hier entscheidet sich, ob das Vorhaben beim Bürger überhaupt ankommt. Eine Empfehlung ohne nationale Umsetzung ist ein Papier.
• Wo landet die Haltegrenze des digitalen Euro? Sie ist die einzige Zahl in diesem ganzen Themenfeld, die direkt bestimmt, wie viel Erspartes ein Bürger in Zentralbankgeld halten darf. Sie steht bis heute nirgends.
• Was passiert mit dem Finanzrahmen 2028 bis 2034? Fällt er deutlich kleiner aus, steigt der Druck, die Lücke privat zu schliessen. Das ist der Zusammenhang, den beide Seiten der Haushaltsdebatte ungern ausbuchstabieren.

Fazit: Wer auf den Zwang wartet, übersieht die Verschiebung

Die Spar- und Investitionsunion nimmt euch nichts weg. Sie kann es nicht, sie will es nicht, und sie hat dafür auch keine Rechtsgrundlage. Wer das behauptet, macht denselben Fehler wie bei der Zweigstellenpflicht für Drittstaatsbanken: Er sucht nach einem Verbot und übersieht dabei, dass moderne Regulierung überhaupt nicht mehr mit Verboten arbeitet.

Was tatsächlich geschieht, ist unspektakulärer und wirksamer. Die Bedingungen werden verschoben, unter denen Geld sich bewegt: Eigenkapitalregeln, Sorgfaltspflichten, Steuervorteile, Meldepflichten, Aufsichtszuständigkeiten. Niemand wird gezwungen. Es wird nur teurer, das eine zu tun, und billiger, das andere. Am Ende ändert sich, wo zehn Billionen Euro liegen, und keine einzige Person hat je eine Entscheidung getroffen, gegen die sie hätte klagen können.

Und die eigentliche Frage stellt sich erst danach. Solange Geld physisch existiert und in Geschäftsbanken liegt, braucht Lenkung Anreize — und Anreize kosten Verhandlungen, Kompromisse und Zeit. Sollte Geld eines Tages vollständig digital und zentral ausgegeben sein, wäre dieser Aufwand nicht mehr nötig. Das ist heute kein Plan, es ist keine Absicht, und es steht in keinem Dokument. Es ist nur die Eigenschaft eines Systems, das gerade gebaut wird. Wer wissen will, ob die Spar- und Investitionsunion gefährlich ist, sollte deshalb nicht auf sie schauen, sondern auf die Zahl, die irgendwann in einem Kommissionsrechtsakt festlegt, wie viele digitale Euro ihr besitzen dürft.

Quellen und weiterführende Links

• Europäische Kommission, SPEECH/26/1765: Rede von Präsidentin von der Leyen bei „La Rencontre des Entrepreneurs de France 2026", Paris, 27.08.2026
• Europäische Kommission: Spar- und Investitionsunion — bessere finanzielle Möglichkeiten, 19.03.2025
• Europäische Kommission, GD FISMA: Savings and Investments Union — Übersicht der Rechtsakte und Termine
• Europäische Kommission: Revitalising EU securitisation, Vorschlag vom 17.06.2025
• Europäische Kommission: Empfehlung zu Spar- und Investitionskonten, 30.09.2025
• Rat der Europäischen Union: Savings and investments union — Arbeitsstränge und Verfahrensstand
• Europäische Kommission: Vorschlag für den mehrjährigen Finanzrahmen 2028–2034, 16.07.2025
• Bundesministerium der Finanzen: Die Weiterentwicklung der europäischen Spar- und Investitionsunion, Monatsbericht Oktober 2025
• Wissenschaftlicher Dienst des Europäischen Parlaments: Savings and investments union — overview and state of play, 19.11.2025
• Orrick: European Parliament Finalises Securitisation Regulation and CRR Reform Proposals Ahead of Trilogue, Mai 2026
• taz: Streit um EU-Budget — Merz prescht mit „Gipfel der Geizigen" vor, 27.08.2026
• Berliner Zeitung: Von der Leyen — Europas Sparer sollen Investoren werden, 30.08.2026
• Europäische Zentralbank: Projektseite zum digitalen Euro

The post Spar- und Investitionsunion: Zwang braucht es nicht appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

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.

Update vom 04.09.2026

Scheinbar funktioniert der Aurora Store wieder problemlos, ich konnte heute 25 Apps in einem Rutsch updaten. User im Kuketz Forum berichten ebenfalls dass sie ihre Apps wieder updaten können. Nichts desto trotz habe ich bei dieser Gelegenheit nochmals meine Apps unter die Lupe genommen und es wurden einige deinstalliert, die ich eigentlich garnicht brauche.

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