Dieser Artikel erklärt verständlich, wie diese Mechanismen funktionieren und warum sie so wichtig sind.

Die drei Standard-Datenströme unter Linux

Jedes Programm unter Linux besitzt automatisch drei sogenannte Standard-Streams:

Diese drei Kanäle bilden die Grundlage für die Kommunikation zwischen Programmen.

stdin (Standard Input)
Hierüber erhält ein Programm Daten. Meist kommt diese Eingabe von der Tastatur oder von einem anderen Programm.

stdout (Standard Output)
Hierüber gibt ein Programm seine normale Ausgabe aus. Standardmäßig wird diese im Terminal angezeigt.

stderr (Standard Error)
Fehlermeldungen werden über einen eigenen Kanal ausgegeben, getrennt von der normalen Ausgabe.

Der große Vorteil dieses Konzepts ist, dass sich diese Datenströme flexibel umleiten oder miteinander verbinden lassen.

Ein einfaches Beispiel

Ein klassischer Befehl:

echo "Hallo Welt"

Das Programm echo schreibt den Text auf stdout, und das Terminal zeigt ihn an:

Hallo Welt

Die Ausgabe wird also vom Programm erzeugt und über den Standard-Ausgabekanal an das Terminal geschickt.

Ausgabe in Dateien umleiten

Mit dem >-Operator lässt sich die Standardausgabe in eine Datei umleiten.

ls > dateiliste.txt

Die Dateiliste wird jetzt nicht mehr im Terminal angezeigt, sondern in die Datei dateiliste.txt geschrieben.

Fehler getrennt speichern

Da Fehlermeldungen über stderr laufen, können sie separat umgeleitet werden:

ls /existiert /nichtda 2> fehler.txt

Hier passiert folgendes:

• Die normale Ausgabe geht weiterhin ins Terminal.
• Die Fehlermeldungen landen in der Datei fehler.txt.

stdout und stderr zusammenführen

Oft möchte man sowohl normale Ausgabe als auch Fehler gemeinsam in einer Datei speichern. Dafür gibt es die bekannte Umleitung:

command > output.log 2>&1

Bedeutung:

1. > output.log leitet stdout in die Datei um
2. 2>&1 sorgt dafür, dass stderr an denselben Ort geschickt wird

Das Ergebnis: Beide Ausgaben landen im gleichen Logfile.

Ein wichtiger Punkt dabei ist die Reihenfolge.
Die korrekte Variante lautet:

command >file 2>&1

Wenn man die Reihenfolge vertauscht, funktioniert die Umleitung nicht wie erwartet.

Anhängen statt Überschreiben

Mit >> wird eine Datei nicht überschrieben, sondern erweitert:

command >> logfile 2>&1

Neue Ausgaben werden dann am Ende der Datei angehängt.

Diese Form sieht man häufig bei Logfiles.

Das schwarze Loch: /dev/null

Unter Linux existiert eine spezielle Gerätedatei namens:

/dev/null

Alles, was dorthin geschrieben wird, verschwindet einfach.

Man nennt sie deshalb oft scherzhaft ein schwarzes Loch für Daten.

Ausgabe unterdrücken

command > /dev/null

Die normale Ausgabe verschwindet, Fehlermeldungen bleiben sichtbar.

Alles unterdrücken

command > /dev/null 2>&1

Jetzt werden sowohl stdout als auch stderr verworfen.

Diese Technik wird häufig in Scripts oder Cronjobs eingesetzt, wenn man bewusst keine Ausgabe erzeugen möchte.

Programme miteinander verbinden (Pipes)

Ein besonders mächtiges Unix-Konzept sind Pipelines.

Dabei wird die Ausgabe eines Programms direkt zur Eingabe eines anderen Programms weitergeleitet.

ps aux | grep python

Ablauf:

1. ps aux erzeugt eine Prozessliste über stdout
2. Die Pipe | leitet diese Ausgabe weiter
3. grep bekommt die Daten über stdin und filtert sie

So lassen sich komplexe Aufgaben aus vielen kleinen Werkzeugen zusammensetzen.

Moderne Anwendungen: systemd und Docker

Viele moderne Dienste nutzen das stdout/stderr-Prinzip direkt für Logging.

systemd

Services schreiben ihre Logs einfach auf stdout oder stderr.
systemd speichert diese automatisch im Journal.

Logs anzeigen:

journalctl -u servicename

Live-Logs:

journalctl -u servicename -f

Docker

Auch Container folgen diesem Prinzip. Anwendungen schreiben Logs einfach auf stdout.

Abrufen der Logs:

docker logs containername

Live verfolgen:

docker logs -f containername

Deshalb besitzen viele Container gar keine eigenen Logfiles mehr.

Fazit

Das stdout/stderr-Konzept gehört zu den elegantesten Ideen im Unix-Design. Es erlaubt:

• flexible Umleitung von Ausgaben
• getrennte Behandlung von Fehlern
• einfache Verknüpfung von Programmen
• sauberes Logging in modernen Systemen

Wer regelmäßig mit Linux arbeitet, wird diese Mechanismen ständig verwenden – oft sogar ohne es bewusst zu merken.

Gerade in Shell-Scripts und bei der Serveradministration sind sie unverzichtbar.

Wenn man das Prinzip einmal verstanden hat, öffnet sich eine der größten Stärken von Unix-Systemen: kleine Werkzeuge lassen sich beliebig kombinieren.

The post stdout, stderr und /dev/null – Die wichtigsten Linux-Datenströme verständlich erklärt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Doch es gibt ein drittes Puzzleteil, das dieses Bild vervollständigt und die Bedrohung auf eine neue Ebene hebt: die Firma Palantir Technologies und ihr Zusammenspiel mit dem US-Biometriesystem HART. Während CLOUD Act und FISA Section 702 den rechtlichen Rahmen für Datenabschöpfung liefern, stellt Palantir die Technologie bereit, um diese Daten zu verknüpfen, zu analysieren und in verwertbare Informationen umzuwandeln. Und das Beunruhigendste daran: Diese Technologie hält gerade Einzug bei der deutschen Polizei.

Palantir: Vom CIA-Startup zum globalen Überwachungskonzern

Die Ursprünge: Silicon Valley trifft Geheimdienst

Die Geschichte von Palantir Technologies beginnt dort, wo man es erwarten würde: an der Schnittstelle zwischen Silicon Valley und dem US-Geheimdienstapparat. Im Jahr 2003 gründete der libertäre Tech-Milliardär Peter Thiel – bereits bekannt als Mitgründer von PayPal – zusammen mit mehreren Mitgründern das Unternehmen in Palo Alto. Die entscheidende Anschubfinanzierung kam von In-Q-Tel, dem Risikokapitalarm der CIA. Dieser Umstand allein sollte jedem in Europa die Alarmglocken schrillen lassen.

Der Name „Palantir" ist dabei kein Zufall. In J.R.R. Tolkiens „Herr der Ringe" sind die Palantíri magische Sehsteine, die den Blick an weit entfernte Orte ermöglichen. Mächtig, verführerisch – aber auch gefährlich, denn wer hineinblickt, riskiert, selbst beobachtet zu werden. Die Symbolik hätte kaum treffender sein können.

Das Unternehmen vertritt die Philosophie der „Augmented Intelligence" – der erweiterten Intelligenz. Die Grundidee: Künstliche Intelligenz allein reicht nicht aus, um komplexe Bedrohungen zu erkennen. Stattdessen braucht man menschliche Analysten, die mit Hilfe von Software riesige Datenmengen aus unterschiedlichsten Quellen zusammenführen und auswerten können. Was zunächst für die Terrorismusbekämpfung entwickelt wurde, ist längst zu einem universellen Überwachungsinstrument geworden.

Zwei Produkte, ein Ziel: Totale Datenverknüpfung

Palantir betreibt zwei Hauptprodukte, die ihr kennen solltet:

Gotham ist das Flaggschiff für Geheimdienste, Militär und Strafverfolgung. Es wurde entwickelt, um Verbindungen zwischen Personen, Orten, Objekten und Ereignissen zu erkennen und zu visualisieren. Gotham kann strukturierte Daten wie Kontaktlisten, Funkzellenabfragen und Reisehistorien mit unstrukturierten Daten wie Fotos, Videoaufnahmen und Textdokumenten verknüpfen. Zu den Kunden gehören die CIA, die NSA, das FBI, das US-Verteidigungsministerium, ICE (Immigration and Customs Enforcement) und – wie ihr gleich erfahren werdet – auch deutsche Polizeibehörden.

Foundry richtet sich an Unternehmen und zivile Behörden und hilft dabei, massive Datensätze zu vereinheitlichen und zu visualisieren. Während der COVID-19-Pandemie bot Palantir Regierungen weltweit Foundry kostenlos an – ein Angebot, das Großbritannien und Griechenland annahmen. Hessen hatte ebenfalls Interesse bekundet, entschied sich letztlich aber dagegen. Die Strategie dahinter ist offensichtlich: Kostenloser Einstieg, langfristige Abhängigkeit.

Palantir und der US-Überwachungsapparat: Eine symbiotische Beziehung

Palantirs Verwicklung in den US-Überwachungsapparat ist nicht bloß historisch. Sie ist aktuell und tiefgreifend. Seit 2013 liefert Palantir der Einwanderungsbehörde ICE Systeme wie FALCON und das Investigative Case Management (ICM). Diese Werkzeuge wurden nachweislich bei Arbeitsplatzrazzien, groß angelegten Durchsetzungsoperationen und Ermittlungen gegen Asylsuchende eingesetzt. Im Jahr 2025 ging Palantir noch einen Schritt weiter: Für 30 Millionen Dollar entwickelt das Unternehmen „ImmigrationOS" – eine KI-gestützte Plattform, die Einwanderer identifizieren, verfolgen und für Abschiebungen markieren soll. Der Prototyp sollte bis September 2025 stehen.

Palantirs Systeme ziehen dabei Daten aus einer Vielzahl von Regierungsdatenbanken: Passregister, Sozialversicherungsdaten, IRS-Steuerdaten, Kennzeichenerfassungssysteme und – das ist der entscheidende Punkt – biometrische Datenbanken. Hier kommt HART ins Spiel.

Und hier wird auch die Verbindung zu unseren vorangegangenen Artikeln deutlich: Palantir unterliegt als US-Unternehmen sowohl dem CLOUD Act als auch FISA Section 702. Wie wir in unserem FISA-Artikel beschrieben haben, wurde Section 702 im April 2024 durch den RISAA (Reforming Intelligence and Securing America Act) erheblich ausgeweitet. Die neue Definition von „Electronic Communications Service Providers" ist so breit gefasst, dass praktisch jedes Unternehmen mit Zugang zu Kommunikationsinfrastruktur zur Kooperation mit US-Geheimdiensten gezwungen werden kann. Die brisante Frage, welchen konkreten Verpflichtungen Palantir nach dem verschärften FISA unterliegt und was das für Daten in deutschen Polizeisystemen bedeutet, wurde bei einer Anhörung im Bundestag-Innenausschuss im April 2024 von keinem einzigen Abgeordneten gestellt.

HART: Die größte biometrische Datenbank der Welt

Was ist HART?

Während Palantir die Analysetechnologie liefert, wird auf der anderen Seite des Atlantiks eine Datenbank aufgebaut, die das Rückgrat der US-Überwachungsinfrastruktur bilden soll: HART – Homeland Advanced Recognition Technology. Dieses System wird vom US-Department of Homeland Security (DHS) entwickelt und soll die veraltete IDENT-Datenbank ablösen, die bereits heute Informationen über mehr als 300 Millionen Personen enthält und täglich rund 350.000 biometrische Transaktionen verarbeitet.

HART ist nicht einfach nur ein Upgrade. Es ist ein Quantensprung in der Überwachungskapazität. Das System wird mindestens sieben verschiedene biometrische Identifikatoren unterstützen: Fingerabdrücke, Gesichtserkennung, Iris-Scans, DNA-Profile, Stimmerkennung, Narben und Tätowierungen – sowie eine offene Kategorie für „andere Modalitäten". In jüngsten Dokumenten hat das DHS diese Definition sogar noch erweitert: Tipprhythmus, Herzsignatur und Gefäßmuster stehen ebenfalls zur Diskussion.

Umfang und Kosten: Zahlen, die schwindelig machen

HART ist ein Projekt der Superlative. Das geplante Budget beträgt 6,158 Milliarden Dollar. Das System soll Daten für mindestens 75 Jahre speichern. Es wird voraussichtlich 6,7 Millionen Iris-Scans und 1,1 Milliarden Gesichtsbilder initial aufnehmen. Und es wird nicht nur biometrische Daten enthalten, sondern auch biografische Informationen wie Namen, Geburtsdaten, Herkunftsländer, Regierungs-IDs – sowie höchst subjektive Daten wie „Beziehungsmuster" und „Begegnungsdaten" aus Polizeikontakten.

HART wird auf der Amazon Web Services (AWS) GovCloud gehostet – derselben Infrastruktur, auf der auch andere DHS-Systeme laufen. Mehr als 41 Menschenrechtsorganisationen, darunter Access Now, die Electronic Privacy Information Center (EPIC) und Mijente, haben AWS in einem öffentlichen Brief aufgefordert, das Hosting einzustellen. Ihre Warnung: AWS ermöglicht damit die Schaffung einer invasiven Biometriedatenbank, die Überwachung und Abschiebungen auf ein neues Niveau heben wird.

Wer landet in HART – und wer hat Zugriff?

HART erfasst nicht nur verdächtige Personen oder Einwanderer. In der Datenbank landen auch US-Bürger und Personen, die niemals eine Straftat begangen haben. Jede Person, die jemals einen Kontakt mit dem DHS hatte – sei es bei einer Grenzkontrolle, einem Visumantrag, einer Einbürgerung oder auch nur als Zeuge – kann in HART erfasst werden. Jeder solcher „Encounter" wird protokolliert und kann in einem Feedbackloop zu weiteren Überprüfungen führen.

Der Zugriff auf HART ist dabei keineswegs auf das DHS beschränkt. Das System wird mit föderalen Behörden wie dem FBI geteilt, mit Bundesstaats- und Kommunalpolizei und – hier wird es für euch als Europäer besonders relevant – mit ausländischen Regierungen. Europol hat operative Abkommen mit den USA im Bereich „ausländische Kämpfer", und Daten fließen über das FBI als Vermittler auch an europäische Behörden. Im Bereich der Terrorismusbekämpfung verschwimmen die Grenzen zwischen nationalen und internationalen Datenbeständen zunehmend.

HART und Palantir: Das perfekte Zusammenspiel

Palantir ist zwar nicht direkt an der Entwicklung von HART beteiligt, aber das Unternehmen liefert die Analyseplattformen, die auf genau diese Daten zugreifen. Palantirs ICM (Investigative Case Management) und FALCON können Informationen aus IDENT/HART mit Daten aus Dutzenden anderen Quellen verknüpfen – Steuerdaten, Kennzeichenerfassung, Soziale Medien, Fluggastdaten. Die neue ImmigrationOS-Plattform wird diese Integration noch vertiefen.

Die Kombination ist bestechend einfach: HART sammelt und speichert die biometrischen und biografischen Daten von Hunderten Millionen Menschen. Palantir analysiert diese Daten, erkennt Muster, erstellt Profile und markiert Zielpersonen. FISA Section 702 und der CLOUD Act liefern die rechtliche Grundlage für den Zugriff – auch auf Daten, die bei europäischen Tochtergesellschaften von US-Firmen liegen. Was in unseren vorangegangenen Artikeln als theoretische Bedrohung beschrieben wurde, manifestiert sich hier in konkreter Technologie.

Und das DHS gibt offen zu, dass es die Genauigkeit und Qualität der Daten in HART nicht gewährleisten kann, da viele Daten von Drittparteien stammen – darunter auch kommerzielle Anbieter wie LexisNexis und Clearview AI. Trotzdem sollen diese fehlerhaften Daten 75 Jahre lang aufbewahrt werden. Die Redress-Mechanismen – also die Möglichkeiten für Betroffene, ihre Daten einzusehen, zu korrigieren oder löschen zu lassen – sind praktisch nicht existent.

Palantir in Europa: Die stille Expansion

Europol: Der Einstieg durch die Hintertür

Palantirs Einzug in Europa begann nicht in Deutschland, sondern bei Europol in Den Haag. Nach den Terroranschlägen in Paris im November 2015 richtete Europol die Taskforce „Fraternité" ein. Über den niederländischen Arm der Unternehmensberatung Capgemini – und nicht direkt über Palantir – wurde Gotham beschafft und ab 2016 getestet. Seit Mitte 2017 setzte Europol die Software für die operative Analyse aller terrorismusbezogenen Daten ein.

Die verschlungene Beschaffung über Capgemini als Zwischenhändler wirft bis heute Fragen auf. Der Rahmenvertrag wurde bereits 2012 geschlossen – vier Jahre vor dem ersten dokumentierten Einsatz. Die EU-Kommission erläuterte nie, wofür die Software in dieser Zwischenzeit genutzt wurde. Die Ausgabenobergrenze lag bei 7,5 Millionen Euro; tatsächlich ausgegeben wurden rund vier Millionen.

Besonders brisant: Europol teilte die Analyseergebnisse nicht nur mit EU-Mitgliedstaaten, sondern auch mit Drittstaaten – darunter den USA. Im Bereich „ausländische Kämpfer" flossen Daten über das FBI direkt an US-Behörden. Dies geschah parallel zu einer Zeit, in der der EuGH das Privacy-Shield-Abkommen kippte und feststellte, dass die USA kein angemessenes Datenschutzniveau bieten.

Laut dem Vize-Direktor von Europol wurde das Palantir-System schließlich 2021 durch eine Eigenentwicklung ersetzt – offiziell wegen mangelnder Kompatibilität mit anderen Europol-Systemen. Europol gab auf Journalistenanfragen allerdings nur zwei von 69 relevanten Dokumenten frei. Aus einem davon geht hervor, dass Europol sogar rechtliche Schritte gegen Palantir wegen Leistungsmängeln erwogen, diese jedoch aus Kostengründen verworfen hatte.

Palantir bei der deutschen Polizei: Von Hessendata zu VeRA

Hessen: Der Pionier (seit 2017)

Hessen war das erste Bundesland, das Palantirs Gotham unter dem Namen „Hessendata" einführte. 2017 beschaffte das Innenministerium die Software – der Preis wurde aus „Gründen des Sicherheitsinteresses" nicht veröffentlicht. Offiziell ging es um Terrorismusbekämpfung und organisierte Kriminalität. In der Praxis sieht es anders aus: In Hessen greifen Polizeibehörden jährlich rund 15.000 Mal auf das System zu. Nur in etwa einem von zwanzig Fällen steht dies im Zusammenhang mit schweren Gefahren. Die Software wurde unter anderem bei der Aufklärung von Geldautomatensprengungen und – deutlich weniger dramatisch – bei Fahrraddiebstählen eingesetzt.

Hessens Innenminister Roman Poseck (CDU) verteidigt den Einsatz: Ein Verzicht würde eine „spürbare Sicherheitslücke" hinterlassen. Datenschützer sehen das anders: Hessendata verknüpft polizeiliche Datenbanken mit Social-Media-Daten. Dass dabei keine Daten in die USA übertragen werden, ist zwar vertraglich zugesichert – aber nur schwer nachprüfbar.

Nordrhein-Westfalen: DAR

Auch Nordrhein-Westfalen nutzt eine angepasste Version von Palantir unter der Bezeichnung DAR (Datenbankübergreifende Analyse und Recherche). Mit Hilfe der Software konnten Ermittler das bisher größte Missbrauchsnetzwerk in Deutschland aufdecken, das 2021 in Bergisch Gladbach zerschlagen wurde. Dieser Erfolg wird regelmäßig als Argument für die Software angeführt.

Bayern: VeRA und der Rahmenvertrag (seit 2024)

Im Spätsommer 2024 startete Bayern den Einsatz der Palantir-Software VeRA (Verfahrensübergreifende Recherche- und Analyseplattform). Bayern hat dabei eine Schlüsselrolle: Das Bayerische Landeskriminalamt schloss nach einem EU-weiten Vergabeverfahren einen Rahmenvertrag mit Palantir, der es allen Polizeibehörden des Bundes und der Länder ermöglicht, sich ohne eigenes Vergabeverfahren anzuschließen. Der Preis: 5,4 Millionen Euro Anschaffungskosten plus 500.000 Euro jährliche Betriebskosten.

VeRA führt verschiedene Datenbanken zusammen, die Informationen über mehr als 30 Millionen Menschen enthalten, und durchsucht sie präventiv. Der bayerische Datenschutzbeauftragte bewertete das Vorgehen als unverhältnismäßig, da auch Daten unbescholtener Personen einbezogen werden. Im LKA Bayern arbeiten mittlerweile rund 200 geschulte Analysten mit der Software.

Baden-Württemberg: Der jüngste Beitritt (2025)

Im November 2025 stimmte der Landtag Baden-Württemberg trotz erheblicher Widerstände – auch aus den Reihen des grünen Koalitionspartners – für die Einführung von Palantir. Eine Petition sammelte 13.000 Unterschriften dagegen. Eine Urabstimmungsinitiative bei den Grünen wurde eingereicht. Landespolizeipräsidentin Stefanie Hinz erklärte vor dem Landtag, Palantir sei der „technologische Marktführer" und es gebe keine vergleichbaren, zeitnah verfügbaren Alternativen.

Langfristig will Baden-Württemberg gemeinsam mit Partnern wie Airbus Defence and Space und Schwarz Digits (der IT-Sparte der Schwarz Gruppe) eine eigene, souveräne Software entwickeln. Bis dahin nutzt man Palantir. Ein Versprechen, das den Lock-in-Effekt praktisch garantiert: Ist das System erst einmal implementiert und die Polizei darauf geschult, wird ein Wechsel extrem teuer und aufwendig.

Bundesebene: Dobrindt prüft, die SPD bremst

Seit Sommer 2025 prüft das Bundesinnenministerium unter Alexander Dobrindt (CSU) den bundesweiten Einsatz. Dobrindt erklärte öffentlich, er habe „kein Störgefühl gegenüber einer Software, nur weil sie vom Anbieter Palantir kommt." Bundesjustizministerin Hubig (SPD) äußerte sich dagegen skeptisch und betonte, es könnten nur rechtsstaatlich konforme Mittel eingesetzt werden.

Im Koalitionsvertrag der schwarz-roten Bundesregierung ist zwar von „automatisierter Datenrecherche und -analyse" mittels KI die Rede. Bedingung sei jedoch die Wahrung verfassungsrechtlicher Vorgaben und der „digitalen Souveränität". Ob Palantir diese Bedingungen erfüllt, ist mehr als fraglich.

Weitere europäische Kunden

Deutschland steht mit seinem Palantir-Einsatz nicht allein. Frankreichs Inlandsgeheimdienst DGSI setzt die Software ein. Großbritannien nutzte Palantir-Produkte im Gesundheitswesen. Polen setzt sie auf dem Arbeitsmarkt ein. Und die NATO hat einen Vertrag mit dem US-Unternehmen geschlossen. Die stille Expansion schreitet voran.

Das Bundesverfassungsgericht zieht Grenzen – und wird ignoriert

Am 16. Februar 2023 fällte das Bundesverfassungsgericht ein wegweisendes Urteil. Die Verfassungsbeschwerden, eingereicht von der Gesellschaft für Freiheitsrechte (GFF), richteten sich gegen die gesetzlichen Grundlagen für den Einsatz von Palantir-Software in Hessen und Hamburg. Das Gericht urteilte klar: Die bestehenden Regelungen sind verfassungswidrig. Sie verstoßen gegen das Recht auf informationelle Selbstbestimmung (Art. 2 Abs. 1 i.V.m. Art. 1 Abs. 1 GG).

Die zentrale Aussage des Gerichts: „Die Befugnisse lassen die automatisierte Verarbeitung unbegrenzter Datenbestände mittels rechtlich unbegrenzter Methoden zu." Data Mining, KI-Einsatz und Predictive Policing werden weder ausgeschlossen noch rechtlich eingeschränkt. Das Gericht forderte mindestens eine „konkretisierte Gefahr" als Eingriffsanlass.

Das Urteil hätte ein Wendepunkt sein können. Stattdessen geschah Folgendes: Die betroffenen Bundesländer passten ihre Polizeigesetze formal an – und machten im Wesentlichen weiter wie bisher. Hessen überarbeitete Hessendata, schwärzt nun Opfernamen und passte einige Features an. Bayern erließ ein neues Polizeiaufgabengesetz, das den Einsatz „konform" zum Urteil ermöglichen soll. Im Juli 2025 reichte die GFF jedoch eine erneute Verfassungsbeschwerde ein – diesmal gegen Bayerns VeRA-Einsatz, da die neuen Regelungen weiterhin unverhältnismäßig seien und keine wirksamen Kontroll- und Schutzmechanismen vorsehen.

Warum Palantir bei der deutschen Polizei ein Souveränitätsproblem ist

Die FISA-Frage, die niemand stellt

Hier kommen unsere früheren Artikel direkt zum Tragen. Palantir Technologies ist ein US-Unternehmen mit Hauptsitz in Denver, Colorado. Es unterliegt uneingeschränkt US-amerikanischem Recht – einschließlich dem CLOUD Act und FISA Section 702.

Wie wir in unserem CLOUD-Act-Artikel ausführlich dargelegt haben, können US-Behörden von US-Unternehmen die Herausgabe von Daten verlangen – unabhängig davon, wo diese Daten gespeichert sind. Und wie unser FISA-Artikel zeigt, verpflichtet Section 702 US-Unternehmen zur Kooperation mit der NSA bei der Überwachung von Nicht-US-Bürgern.

Die entscheidende, unbeantwortete Frage lautet: Welchen konkreten Verpflichtungen unterliegt Palantir nach dem verschärften FISA? Kann die NSA Palantir anweisen, über Gotham/VeRA gewonnene Erkenntnisse aus deutschen Polizeidatenbanken herauszugeben? Palantir beteuert, selbst keine Daten zu sammeln, zu verkaufen oder für eigene Zwecke zu verarbeiten. Doch das ist nicht die relevante Frage. Die relevante Frage ist, ob Palantir auf Anweisung von US-Behörden Zugriff auf Daten gewähren muss, die über seine Software verarbeitet werden.

Innenminister Dobrindt verweist auf ein Gutachten des Fraunhofer-Instituts, das den Vorwurf von Datenabflüssen widerlege. Doch dieses Gutachten prüfte den Quellcode zu einem bestimmten Zeitpunkt. Ein Software-Update kann die Situation jederzeit ändern. Und die rechtliche Verpflichtung eines US-Unternehmens zur Kooperation mit US-Geheimdiensten lässt sich nicht durch ein technisches Gutachten widerlegen – sie ergibt sich aus dem Gesetz.

Die Starlink-Lehre

Die Kritiker verweisen auf ein anschauliches Beispiel: den Starlink-Einsatz in der Ukraine. Dort hat sich gezeigt, wie ein einzelnes US-Tech-Unternehmen durch politisch motivierte Entscheidungen massiven Einfluss auf die Sicherheitslage eines ganzen Landes nehmen kann. Die Vorstellung, dass die innere Sicherheit Deutschlands von den Geschäftsentscheidungen eines Unternehmens in Colorado abhängt, dessen Gründer Peter Thiel einer der größten Unterstützer von Donald Trump ist, sollte jeden demokratisch gesinnten Bürger beunruhigen.

Blackbox-Algorithmen und demokratische Kontrolle

Ein weiteres fundamentales Problem: Gotham ist proprietäre Software. Der Quellcode ist ein Geschäftsgeheimnis. Entscheidungen, die auf den Analysen von Palantir beruhen, sind für Betroffene nicht nachvollziehbar. Wie soll man sich gegen einen Verdacht wehren, dessen Zustandekommen man nicht versteht? Wie sollen Gerichte die Rechtmäßigkeit einer Maßnahme prüfen, wenn die entscheidenden Algorithmen ein Geschäftsgeheimnis sind?

Constanze Kurz, Sprecherin des Chaos Computer Clubs, bringt es auf den Punkt: Die zusammengeführten Daten landen in einer „absichtlich undurchschaubaren Software des US-Konzerns Palantir, von der sich die Polizei auf Jahre abhängig macht." Das seien klare Ausschlusskriterien für Daten aus dem Innenleben der Polizei.

Wer landet im System?

Die Palantir-Software erfasst nicht nur Tatverdächtige. Wer als Zeuge bei einem Autounfall aussagt, Anzeige gegen jemanden erstattet oder einfach nur am selben Bahnhof in eine Kontrolle gerät wie eine gesuchte Person, kann im System landen. Auch Opfer von Straftaten, Kontaktpersonen, Auskunftspersonen – sie alle sind in den polizeilichen Datenbanken gespeichert, die Palantir durchforstet.

Die GFF warnte ausdrücklich: „Schon wer Anzeige erstattet, Opfer einer Straftat wird oder einfach nur zur falschen Zeit am falschen Ort ist, kann durch die Software ins Visier der Polizei geraten." Besonders alarmierend ist dies im Kontext des Erstarkens rechtsextremer Kräfte. Gelangt die AfD in eine Landesregierung, könnte sie theoretisch auf Palantir-Systeme zugreifen und diese für ihre Zwecke nutzen – etwa nach dem Vorbild der Trump-Administration zur gezielten Erfassung und Abschiebung von Menschen.

Die Verbindung: Vom CLOUD Act über FISA Section 702 zu HART und Palantir

Für diejenigen unter euch, die unsere Artikelserie verfolgt haben, wird nun das Gesamtbild deutlich. Es handelt sich nicht um isolierte Bedrohungen, sondern um ein ineinandergreifendes System:

Der CLOUD Act (Artikel 1 dieser Serie) schafft die rechtliche Grundlage dafür, dass US-Behörden von US-Unternehmen wie Palantir die Herausgabe von Daten verlangen können – unabhängig davon, ob diese auf Servern in Deutschland, den Niederlanden oder anderswo in der EU liegen.

FISA Section 702 (Artikel 2 dieser Serie) ermöglicht es der NSA, die Kommunikation von Nicht-US-Bürgern anlasslos und massenhaft zu überwachen – über US-Anbieter wie die, deren Infrastruktur Palantir nutzt. Seit der RISAA-Erweiterung 2024 ist der Kreis der zur Kooperation verpflichteten Unternehmen erheblich gewachsen.

HART sammelt biometrische und biografische Daten von Hunderten Millionen Menschen in einer zentralisierten Datenbank, die mit US-Behörden, lokaler Polizei und ausländischen Regierungen geteilt wird.

Palantir liefert die Technologie, die all diese Datenströme zusammenführt, analysiert und in verwertbare Informationen umwandelt. Und genau diese Technologie wird nun bei der deutschen Polizei eingeführt.

Die Frage, die sich jeder stellen sollte: Wenn ein US-Unternehmen, das von der CIA mitfinanziert wurde, das mit NSA, FBI und ICE zusammenarbeitet, das dem CLOUD Act und FISA Section 702 unterliegt – wenn dieses Unternehmen Zugriff auf die zusammengeführten Datenbanken der deutschen Polizei erhält, die Informationen über mehr als 30 Millionen Menschen enthalten: Wie sicher sind diese Daten dann wirklich vor dem Zugriff der US-Geheimdienste?

Was ihr tun könnt

Die Debatte um Palantir ist noch nicht entschieden. Es gibt Handlungsmöglichkeiten:

Informiert euch und andere. Das größte Problem ist die mangelnde öffentliche Aufmerksamkeit. Die meisten Menschen wissen nicht einmal, dass ihre Daten in Polizeidatenbanken landen können, ohne dass sie jemals verdächtigt wurden – und dass diese Daten nun potenziell mit US-Überwachungstechnologie analysiert werden.

Unterstützt Organisationen, die sich für digitale Grundrechte einsetzen. Die Gesellschaft für Freiheitsrechte (GFF) führt die juristischen Kämpfe gegen den Palantir-Einsatz. Der Chaos Computer Club liefert die technische Expertise. Campact organisiert öffentlichen Druck. Diese Arbeit braucht Unterstützung.

Fordert europäische Alternativen. Die Innenministerkonferenz hat im Juni 2025 beschlossen, eine europäische Alternative zu Palantir suchen zu wollen. Dieser Beschluss muss mit Leben gefüllt werden. Quelloffene, transparente, demokratisch kontrollierbare Software – entwickelt in Europa, für europäische Rechtsstandards.

Setzt euch politisch ein. Schreibt euren Landtags- und Bundestagsabgeordneten. Fragt sie konkret: Welchen FISA-Verpflichtungen unterliegt Palantir? Wie wird garantiert, dass keine Daten an US-Behörden fließen? Warum gibt es keine Transparenz über den Quellcode? Warum wird keine europäische Open-Source-Alternative priorisiert?

Achtet auf eure eigene Datenspur. In unseren vorangegangenen Artikeln haben wir bereits empfohlen, auf europäische Alternativen zu setzen: Nextcloud statt Google Drive, Tuta oder Proton Mail statt Gmail, Signal oder Element/Matrix statt WhatsApp. Jede Entscheidung für einen europäischen Dienst ist eine Entscheidung gegen die Abhängigkeit von US-Technologie.

Fazit: Die Sehsteine von Palantir gehören nicht in europäische Hände

In Tolkiens Welt galt eine simple Wahrheit: Wer die Palantíri leichtfertig nutzt, riskiert, von einer dunkleren Macht beobachtet und manipuliert zu werden. Die Parallelen zur realen Welt sind frappierend.

Palantirs Gotham mag ein leistungsfähiges Werkzeug für die Polizeiarbeit sein. Die Erfolge bei der Aufklärung schwerer Straftaten sind real. Doch der Preis, den wir dafür zahlen, ist zu hoch: die Untergrabung des Grundsatzes der Zweckbindung, die Schaffung einer undurchsichtigen Überwachungsinfrastruktur, die Abhängigkeit von einem US-Unternehmen mit engen Geheimdienstverbindungen, und die faktische Aushöhlung der digitalen Souveränität.

Die Lösung ist nicht, auf moderne Analysetechnologie zu verzichten. Die Lösung ist, europäische, quelloffene, demokratisch kontrollierbare Alternativen zu entwickeln. Bis dahin gilt: Jede Polizeidatenbank, die über Palantir-Software analysiert wird, ist potenziell eine Datenbank, auf die US-Geheimdienste Zugriff haben könnten. Nicht weil Palantir böswillig wäre – sondern weil US-Recht dies ermöglicht und das Unternehmen gar keine Wahl hätte.

Unsere drei Artikel zeigen ein konsistentes Bild: Der CLOUD Act, FISA Section 702, HART und Palantir sind keine voneinander isolierten Phänomene. Sie sind die Zahnräder einer Maschinerie, die darauf ausgelegt ist, globale Datenströme unter US-amerikanische Kontrolle zu bringen. Und Europa öffnet dieser Maschinerie gerade bereitwillig die Tür.

Quellen und weiterführende Informationen

1. Electronic Frontier Foundation (EFF): „HART: Homeland Security's Massive New Database Will Include Face Recognition, DNA, and Peoples' 'Non-Obvious Relationships'" – https://www.eff.org/deeplinks/2018/06/hart-homeland-securitys-massive-new-database-will-include-face-recognition-dna-and
2. Immigrant Defense Project / Just Futures Law / Mijente: „HART Attack: How DHS's Massive Biometrics Database Will Supercharge Surveillance and Threaten Rights" – https://surveillanceresistancelab.org/featured-work/hart-attack-how-dhss-massive-biometrics-database-will-supercharge-surveillance-and-threaten-rights/
3. FedScoop: „Homeland Security centralizes control over the government's largest biometrics database" (August 2025) – https://fedscoop.com/homeland-security-centralizes-control-over-the-governments-largest-biometrics-database/
4. American Immigration Council: „ICE to Use ImmigrationOS by Palantir" (August 2025) – https://www.americanimmigrationcouncil.org/blog/ice-immigrationos-palantir-ai-track-immigrants/
5. Bundesverfassungsgericht: Urteil vom 16. Februar 2023 – 1 BvR 1547/19 – https://www.bundesverfassungsgericht.de/SharedDocs/Entscheidungen/DE/2023/02/rs20230216_1bvr154719.html
6. Gesellschaft für Freiheitsrechte (GFF): Verfassungsbeschwerde gegen Palantir in Bayern (Juli 2025) – https://freiheitsrechte.org/themen/freiheit-im-digitalen/palantir-bayern
7. Handelsblatt: „Palantir erhält Rückendeckung aus der Bundesregierung" (August 2025) – https://www.handelsblatt.com/politik/deutschland/polizei-software-palantir-erhaelt-rueckendeckung-aus-der-bundesregierung/100150618.html
8. Campact: „Nein zum Palantir-Deal" – https://www.campact.de/datenschutz/peter-thiel-palantir-polizei-software-stoppen-petition/
9. Ingenieur.de: „Palantir in Deutschland: Polizei schwärmt, Datenschützer warnen" (November 2025) – https://www.ingenieur.de/technik/fachbereiche/ittk/polizei-schwaermt-datenschuetzer-warnen-palantir-im-deutschen-praxistest/
10. Friedrich-Naumann-Stiftung: „Palantir: Wie eine US-Software den Rechtsstaat zur Blackbox macht" – https://www.freiheit.org/de/deutschland/palantir-wie-eine-us-software-den-rechtsstaat-zur-blackbox-macht
11. Police-IT: „Palantir" (Archiv mit Section-702-Zusammenhang) – https://police-it.net/category/akteure/it_anbieter/palantir
12. Heise Online: „Europol nutzt Palantirs Big-Data-Software Gotham" – https://www.heise.de/news/Neue-Ermittlungsansaetze-Europol-nutzt-Palantirs-Big-Data-Software-Gotham-4781409.html
13. Data Center Dynamics: „Human rights groups call on AWS to stop hosting massive DHS biometric surveillance system" – https://www.datacenterdynamics.com/en/news/human-rights-groups-call-on-aws-to-stop-hosting-massive-dhs-biometric-surveillance-system/
14. NILC: „Homeland Advanced Recognition Technology (HART) Factsheet" – https://www.nilc.org/wp-content/uploads/2021/12/HART-factsheet-2021-11-10.pdf
15. Staatsanzeiger Baden-Württemberg: „Palantir im Südwesten: Was die Polizei-Software bedeutet" (November 2025) – https://www.staatsanzeiger.de/nachrichten/politik-und-verwaltung/palantir-im-suedwesten-was-die-polizei-software-bedeutet/

Dieser Artikel ist Teil einer Serie über den US-Überwachungsapparat und seine Auswirkungen auf europäische Bürger. Die vorangegangenen Artikel behandeln den CLOUD Act und FISA Section 702. Die dargestellten Einschätzungen basieren auf aktuellen Gerichtsurteilen, Berichten von Aufsichtsbehörden und Analysen anerkannter Bürgerrechtsorganisationen (EFF, GFF, CCC, Campact, EPIC), ersetzen jedoch keine individuelle Rechtsberatung. Stand: Februar 2026.

The post Palantir, die Sehsteine der USA in Europa appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was Google vorhat

Im August 2025 hat Google angekündigt, dass ab September 2026 keine Anwendung mehr auf zertifizierten Android-Geräten installiert werden kann, wenn der Entwickler sich nicht zuvor bei Google registriert und verifiziert hat. Das gilt nicht nur für Apps aus dem Play Store – sondern für sämtliche Installationswege, einschliesslich Sideloading und alternative App-Stores wie F-Droid.

Konkret verlangt Google von Entwicklern:

• Die Zahlung einer Gebühr
• Die Zustimmung zu Googles Nutzungsbedingungen
• Die Vorlage eines amtlichen Ausweises (Identitätsverifizierung)
• Den Nachweis über den privaten Signaturschlüssel
• Eine vollständige Liste aller aktuellen und zukünftigen App-Kennungen (Package Names)

Der Rollout soll zunächst in Brasilien, Indonesien, Singapur und Thailand beginnen. Ab 2027 plant Google die weltweite Einführung – also auch in Europa und der Schweiz.

Googles Argumentation – und warum sie nicht überzeugt

Google begründet die Massnahme mit Sicherheit. Laut eigener Analyse enthalten Apps aus Sideloading-Quellen angeblich fünfzigmal mehr Malware als Apps aus dem Play Store. Die Verifizierung soll verhindern, dass böswillige Akteure anonym schädliche Apps verbreiten.

Das klingt auf den ersten Blick nachvollziehbar, hält einer genaueren Prüfung allerdings nicht stand. Denn die Identitätsverifizierung prüft nur, wer der Entwickler ist – nicht, was die App tut. Ein verifizierter Entwickler kann weiterhin problemlos Malware verbreiten. Kriminelle werden schlicht gestohlene Identitäten nutzen oder den Verifizierungsprozess als triviale Hürde betrachten, da sie ohnehin bereits Gesetze brechen. Gleichzeitig werden legitime Entwickler abgeschreckt, die ihre Privatsphäre schützen wollen oder sich nicht von Google abhängig machen möchten.

F-Droid bringt es auf den Punkt: Vertrauen entsteht nicht dadurch, dass man die rechtliche Identität eines Entwicklers überprüft. Ob eine App schädlich ist oder nicht, lässt sich dadurch nicht feststellen – unabhängig davon, ob der Entwickler bei Google verifiziert ist. Die Art, wie F-Droid freie Software direkt aus dem Quellcode baut und an Nutzer verteilt, entspricht dem Prinzip, nach dem die meisten Linux-Distributionen seit Jahrzehnten Software ausliefern, wenn auch mit einigen Nachteilen. Diese Verteilungsmechanismen haben sich über Jahrzehnte bewährt, gelten als extrem sicher und bilden das Rückgrat der modernen Computing-Infrastruktur weltweit. Niemand hat je vorgeschlagen, dass Linux-Distributionen sicherer werden, indem eine zentrale Instanz jeden Entwickler verifiziert.

Was das für Verbraucher bedeutet

Wer ein Android-Gerät gekauft hat, tat dies im Vertrauen auf das Versprechen einer offenen Plattform, auf der jede beliebige Software ausgeführt werden kann. Ab September 2026 wird Google jedoch ohne Zustimmung der Nutzer ein Betriebssystem-Update ausspielen, das dieses Recht dauerhaft einschränkt. Ab diesem Zeitpunkt entscheidet Google, welchen Anwendungen ihr „vertrauen dürft" – und welchen nicht.

Besonders brisant: Diese Änderung betrifft zertifizierte Android-Geräte, also praktisch alle handelsüblichen Smartphones und Tablets, die mit Google-Apps und Play Protect ausgeliefert werden. Das schliesst Samsung, Xiaomi, OnePlus, Motorola, Google Pixel und unzählige weitere Hersteller ein.

Was das für Entwickler bedeutet

Für Entwickler wird es unmöglich, Anwendungen zu erstellen und direkt mit Freunden, Familie oder der eigenen Community zu teilen, ohne zuvor Googles Genehmigung einzuholen. Das ursprüngliche Versprechen von Android – das wichtigste Argument, mit dem sich das System einst vom iPhone abhob – beruhte auf seiner Offenheit. Offenbar ist Google inzwischen überzeugt, genug Kontrolle über das Android-Ökosystem zu besitzen, um dieses Prinzip nun aufzugeben.

Für die Open-Source-Gemeinschaft ist die Lage besonders kritisch. F-Droid, der wichtigste alternative App-Store für freie und quelloffene Android-Software, kann seine Entwickler nicht dazu zwingen, sich bei Google zu registrieren und dafür zu bezahlen. Gleichzeitig kann F-Droid die App-Kennungen nicht einfach übernehmen, da dies faktisch die exklusiven Vertriebsrechte für diese Anwendungen an sich reissen würde. F-Droid hat unmissverständlich erklärt: Googles Registrierungsdekret wird das F-Droid-Projekt und andere freie Distributionsquellen in ihrer heutigen Form beenden.

Was das für Staaten und die digitale Souveränität bedeutet

Regierungen, die sich auf Android-Geräte in der Verwaltung verlassen, überlassen die Kontrolle über die Rechte ihrer Bürger und ihre digitale Souveränität einem US-Konzern. Einem Konzern, der bekannt dafür ist, sich auch aussegerichtlichen Forderungen autoritärer Regime zu beugen, um missliebige – aber völlig legale – Anwendungen zu entfernen. Die für Verwaltung und Wirtschaft unverzichtbare Software wird damit den Launen eines fernen, unkontrollierbaren Unternehmens ausgeliefert.

Gerade für europäische Länder, die sich intensiv um digitale Souveränität bemühen, wäre diese Entwicklung ein herber Rückschlag. Der Digital Markets Act (DMA) der EU soll genau solche Machtkonzentration verhindern – doch ob er gegen Googles Pläne greifen wird, ist noch offen.

Hat Google bei der Entwicklerverifizierung „nachgegeben"

Ende 2025 deutete Google in einem Blogbeitrag vage an, dass es einen „erweiterten Ablauf" geben könnte, der es „erfahrenen Nutzern" eventuell erlaubt, „die Risiken der Installation nicht verifizierter Software zu akzeptieren". Viele Medien berichteten daraufhin, Google habe eingelenkt.

Die Realität sieht anders aus. Googles offizielle Entwicklerseite stellt weiterhin unmissverständlich fest:

Ab September 2026 müssen alle Android-Apps von bestätigten Entwicklern registriert werden, damit sie auf zertifizierten Android-Geräten installiert werden können.

Solange Google keine konkreten Belege dafür vorgelegt hat, dass es möglich sein wird, den Verifizierungsprozess ohne unangemessene Hürden zu umgehen, sollte man dem Glauben schenken, was auf der offiziellen Seite steht: Alle Apps von nicht registrierten Entwicklern werden blockiert.

Custom ROMs sind nicht betroffen – aber das reicht nicht

Ein wichtiger technischer Aspekt: Die Verifizierungspflicht betrifft ausschliesslich zertifizierte Android-Geräte – also solche, die mit Google Mobile Services (GMS) und dem Play-Protect-Framework ausgeliefert werden. Geräte mit Custom ROMs wie GrapheneOS, LineageOS, CalyxOS, /e/OS oder anderen AOSP-basierten Systemen ohne Google-Dienste sind von dieser Einschränkung nicht direkt betroffen. Auf diesen Systemen können weiterhin beliebige APKs installiert werden.

Das klingt zunächst beruhigend – ist es aber nur bedingt. Denn die überwältigende Mehrheit der Android-Nutzer verwendet Standard-Firmware mit Google-Diensten. Custom ROMs sind selbst unter technisch versierten Nutzern eine Nischenerscheinung. Nicht jeder kann oder will sein Gerät mit einem Custom ROM betreiben – sei es wegen mangelnder technischer Kenntnisse, fehlender Geräteunterstützung oder weil bestimmte Apps (Banking, Firmensoftware) ein zertifiziertes Gerät voraussetzen.

Zudem nutzen auch viele Anwender auf Stock-Android bewusst F-Droid und Apps von freien Entwicklern als Ergänzung oder Alternative zum Play Store. Genau diese Nutzer werden durch die neuen Regeln direkt betroffen sein. Es ist daher wichtig, sich auch dann für die Offenheit von Android einzusetzen, wenn man selbst ein Custom ROM nutzt – denn die Vielfalt des Ökosystems lebt davon, dass freie Software auf allen Android-Geräten installiert werden kann, nicht nur auf einer Handvoll Enthusiasten-Geräten.

Es gibt zudem ein weiteres Risiko: Wenn mehr Nutzer auf Custom ROMs ausweichen, um die Verifizierungspflicht zu umgehen, steigt paradoxerweise die Angriffsfläche. Denn das Entsperren des Bootloaders – bei den meisten Geräten die Voraussetzung für ein Custom ROM – deaktiviert die vom Hersteller etablierte Vertrauenskette auf Hardwareebene. Nur wenige Security-fokussierte ROMs wie GrapheneOS unterstützen das erneute Sperren des Bootloaders nach der Installation. Bei allen anderen Geräten bleibt der Bootloader entsperrt – mit entsprechenden Risiken.

Wie ihr helfen könnt

Als Entwickler

Registriert euch nicht für Googles Early-Access-Programm, führt keine Identitätsprüfung durch und akzeptiert keine Einladungen zur Android-Entwicklerkonsole. Nur durch das Einverständnis der Entwickler kann Googles Plan gelingen. Ermutigt andere Entwickler und Organisationen, sich ebenfalls nicht zu registrieren. Nutzt Community-Foren, soziale Netzwerke und Blogs, um die Botschaft zu verbreiten. Die Bibliothek FreeDroidWarn kann in eigene Projekte eingebunden werden, um Nutzer direkt in der App über die Problematik zu informieren.

Als Nutzer

• Installiert F-Droid auf euren Android-Geräten. Je mehr Nutzer alternative Plattformen verwenden, desto schwieriger wird es, sie auszuschliessen.
• Gebt Google direkt Feedback über die Umfrage zu den Anforderungen der Android-Entwicklerverifizierung.
• Macht eure Meinung öffentlich – in sozialen Netzwerken, Foren und Blogs. Verlinkt dabei auf keepandroidopen.org.
• Widersprecht Meinungsmanipulation: Wenn ihr in Foren oder sozialen Medien verdächtige Beiträge seht, die die neue Politik verteidigen, bezieht Stellung.
• Unterschreibt die Petition auf change.org.

Aufsichtsbehörden kontaktieren

Regulierungsbehörden auf der ganzen Welt sind ernsthaft besorgt über Monopole und die zunehmende Machtkonzentration im Technologiesektor. Beschwerden sind besonders wirksam, wenn sie von Bürgern des jeweiligen Landes eingereicht werden und in der Amtssprache verfasst sind.

Für die Europäische Union:

• E-Mail an das DMA-Team: [email protected]
• E-Mail Antitrust: [email protected]
• Beschwerde bei der EU-Wettbewerbspolitik

Für die Schweiz:

• Meldung bei der Wettbewerbskommission (WEKO)

Warum das alle angeht

Was Google hier plant, geht weit über eine technische Änderung hinaus. Es ist ein fundamentaler Bruch mit dem Prinzip, das Android seit seiner Einführung definiert hat: Offenheit. Wenn ein einzelnes Unternehmen entscheiden kann, welche Software auf dem weltweit meistgenutzten Betriebssystem installiert werden darf, hat das weitreichende Konsequenzen – für die Meinungsfreiheit, für den Wettbewerb, für die Innovation und für die digitale Selbstbestimmung jedes einzelnen Nutzers.

Android ist nicht irgendein Produkt. Es läuft auf über drei Milliarden Geräten weltweit. Für viele Menschen – besonders in Entwicklungsländern – ist das Smartphone der einzige Computer, den sie besitzen. Ihnen den Zugang zu freier Software zu verwehren, ist ein Angriff auf ihre digitale Autonomie.

Die Initiative „Keep Android Open" ruft daher alle auf: Informiert euch, erhebt eure Stimme und setzt euch für ein offenes Android ein – bevor es zu spät ist.

Weiterführende Links:

• Keep Android Open – Offizielle Seite
• F-Droid: Googles Entwicklerregistrierungsdekret
• F-Droid: Developer Verification Policy und der DMA
• EFF: Application Gatekeeping – Ein wachsender Weg zur Internetzensur
• ACLU: Your Smartphone, Their Rules
• Heise: Keep Android Open – Abwehr gegen Verbot anonymer Apps von Google

The post Keep Android Open – Google will Android schliessen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist FISA Section 702

Section 702 wurde 2008 als Teil des FISA Amendments Act verabschiedet – in der politischen Atmosphäre nach den Anschlägen vom 11. September 2001. Der offizielle Zweck: Die gezielte Überwachung von Nicht-US-Bürgern außerhalb der USA, um Informationen über Terrorismus, Spionage und die Verbreitung von Massenvernichtungswaffen zu sammeln.

Klingt erst einmal spezifisch und kontrolliert. Doch die Realität sieht völlig anders aus.

Section 702 erlaubt es dem US-Justizminister und dem Direktor der Nationalen Nachrichtendienste, gemeinsam breite Überwachungsprogramme zu genehmigen. Das geheime FISA-Gericht (Foreign Intelligence Surveillance Court, kurz FISC) prüft diese Programme nur auf einer übergeordneten, programmatischen Ebene – es genehmigt keine einzelnen Überwachungsziele. Sobald ein Programm genehmigt ist, können NSA, FBI und CIA eigenständig entscheiden, wen sie ins Visier nehmen. Einzige Bedingung: Das Ziel muss ein Nicht-US-Bürger sein, der sich vermutlich außerhalb der USA aufhält.

Das klingt nach einer Einschränkung. Aber genau hier beginnt das Problem für uns als Europäer.

PRISM und Upstream: Die zwei Säulen der Überwachung

Edward Snowden enthüllte 2013, was viele bereits ahnten: Unter Section 702 betreibt die NSA zwei massive Überwachungsprogramme.

PRISM (heute „Downstream Collection") ist das bekanntere der beiden Programme. Das FBI – als Vermittler zwischen NSA und Privatunternehmen – schickt sogenannte „Selektoren" (E-Mail-Adressen, Telefonnummern, andere Identifikatoren) an US-Technologieunternehmen und verpflichtet diese, alle Kommunikationen herauszugeben, die mit diesen Selektoren in Verbindung stehen. Betroffen sind Unternehmen wie Microsoft, Google, Apple, Meta (Facebook), Yahoo und YouTube. Laut dem FISC war PRISM im Jahr 2011 für rund 91 Prozent der etwa 250 Millionen Internetkommunikationen verantwortlich, die jährlich unter Section 702 erfasst werden.

Lest das nochmal: 250 Millionen Kommunikationen pro Jahr. Allein durch PRISM.

Upstream Collection geht noch einen Schritt weiter. Hier greift die NSA Kommunikationen direkt an der Internet-Backbone-Infrastruktur ab – also an den Glasfaserkabeln und Knotenpunkten, durch die der globale Datenverkehr fließt. Da etwa 80 Prozent des weltweiten Internetverkehrs irgendwann durch US-Infrastruktur geleitet wird, ist die Reichweite dieses Programms enorm. Wenn ihr eine E-Mail an einen Geschäftspartner in Brasilien schickt und diese über einen US-Server geroutet wird, kann die NSA sie abfangen.

Besonders brisant war die sogenannte „Abouts"-Erfassung: Dabei wurden nicht nur Kommunikationen erfasst, die an oder von einem Überwachungsziel gingen, sondern auch solche, die ein Überwachungsziel lediglich erwähnten. Die NSA hat diese Praxis 2017 offiziell eingestellt – aber der RISAA von 2024 hat die Tür für eine Wiedereinführung unter bestimmten Bedingungen offen gelassen.

Die „Nebenbei"-Erfassung: Warum Europäer keine Nebensache sind

Die US-Regierung betont gebetsmühlenartig, dass Section 702 nur auf Ausländer außerhalb der USA abzielt. Was sie weniger gern erwähnt: Bei der Überwachung dieser Ziele werden zwangsläufig auch die Kommunikationen all jener erfasst, die mit diesen Zielen in Kontakt stehen – darunter Millionen von US-Bürgern und Europäern.

Diese sogenannte „Incidental Collection" (nebenbei erfolgende Erfassung) ist alles andere als nebensächlich. Wenn ein europäischer Geschäftsmann mit einem ausländischen Partner kommuniziert, der zufällig auf einer Überwachungsliste steht, landen seine E-Mails, Nachrichten und Anrufe in den Datenbanken der US-Geheimdienste. Und selbst wenn keine direkte Verbindung zu einem Überwachungsziel besteht: Durch die Upstream-Erfassung an der Internet-Backbone werden Kommunikationen quasi im Vorbeigehen mitgelesen.

Für Nicht-US-Bürger gibt es dabei praktisch keinen Schutz. Section 702 gewährt keinerlei Rechte auf Information, Widerspruch oder gerichtliche Überprüfung für ausländische Staatsangehörige. Ihr wisst nicht, ob eure Daten erfasst wurden. Ihr könnt nicht dagegen klagen. Ihr werdet nie informiert.

Backdoor Searches: Wenn das FBI die eigenen Bürger ausspioniert

Doch es kommt noch schlimmer. Die unter Section 702 gesammelten Daten werden in riesigen Datenbanken gespeichert. Und hier beginnt ein Missbrauch, der selbst die Verfechter des Gesetzes in Erklärungsnot bringt.

Das FBI kann diese Datenbanken jederzeit mit den Namen, E-Mail-Adressen oder Telefonnummern von US-Bürgern durchsuchen – die sogenannten „Backdoor Searches" oder „U.S. Person Queries". Kein Durchsuchungsbefehl nötig. Kein Richter. Kein begründeter Verdacht. Einfach den Namen eintippen und die intimsten Kommunikationen lesen.

Die Zahlen sind erschütternd:

• 2021: Das FBI führte bis zu 3,4 Millionen solcher Durchsuchungen durch – in einem einzigen Jahr.
• 2024: Die offiziell gemeldete Zahl sank auf 5.518. Doch das FISA-Gericht stellte fest, dass FBI-Mitarbeiter eine „erweiterte Filterfunktion" nutzten, die zusätzliche, nicht protokollierte Durchsuchungen durchführte. Die tatsächliche Zahl bleibt unbekannt.

Unter den Betroffenen dieser Durchsuchungen befanden sich nachweislich: Teilnehmer von Black-Lives-Matter-Protesten, Verdächtige des 6. Januar 2021, Journalisten, Mitglieder des US-Kongresses, ein US-Senator, ein Staatssenator, ein Staatsrichter, politische Kommentatoren und 19.000 Spender einer einzigen Kongresskampagne.

Das Privacy and Civil Liberties Oversight Board (PCLOB) – die eigentlich zuständige Aufsichtsbehörde – stellte fest, dass es kaum Belege für den Nutzen dieser massenhaften Backdoor-Durchsuchungen gibt. In den wenigen dokumentierten Fällen, in denen sie tatsächlich hilfreich waren, hätte das FBI auch einen regulären Durchsuchungsbefehl erwirken oder sich auf bestehende Ausnahmen berufen können.

Das historische Urteil von 2024: Verfassungswidrig

Im Dezember 2024 fällte Richterin LaShann DeArcy Hall am U.S. District Court für den Eastern District of New York ein wegweisendes Urteil im Fall United States v. Hasbajrami: Die Backdoor-Durchsuchungen von Section-702-Daten verstoßen gegen den vierten Zusatzartikel der US-Verfassung und erfordern grundsätzlich einen richterlichen Durchsuchungsbefehl.

Es war das erste Mal überhaupt, dass ein Gericht diese Praxis für verfassungswidrig erklärte. Der Fall betraf einen US-Einwohner, der 2011 am New Yorker JFK-Flughafen verhaftet wurde. Erst nach seiner ursprünglichen Verurteilung offenbarte die Regierung, dass Teile der Beweismittel aus ohne Durchsuchungsbefehl durchgeführten Section-702-Abfragen stammten.

Die Regierung hat Berufung eingelegt. Aber das Urteil sendet ein klares Signal – auch für die anstehende Debatte um die Verlängerung von Section 702.

RISAA 2024: Mehr Überwachung statt Reform

Statt die dokumentierten Missbräuche einzudämmen, hat der US-Kongress im April 2024 mit dem Reforming Intelligence and Securing America Act (RISAA) Section 702 nicht nur verlängert, sondern ausgeweitet:

Erweiterte Definition von „Electronic Communication Service Provider": Jeder Dienstleister, der Zugang zu Geräten hat, die elektronische Kommunikationen übertragen oder speichern könnten, kann nun zur Kooperation gezwungen werden. Das betrifft potenziell nicht mehr nur klassische Telekommunikationsunternehmen und Internetanbieter, sondern auch Rechenzentren, Cloud-Dienste, Managed-Security-Anbieter – und theoretisch sogar Vermieter oder Wartungspersonal mit Zugang zu Netzwerkinfrastruktur. Senator Ron Wyden nannte dies „eine der dramatischsten und erschreckendsten Erweiterungen der staatlichen Überwachungsbefugnisse in der Geschichte."

Neue Überwachungszwecke: Die Definition von „Foreign Intelligence Information" wurde erweitert, um die internationale Produktion, Verteilung und Finanzierung illegaler Drogen einzuschließen – ein gewaltiger Schritt weg von der ursprünglichen Antiterrorismus-Begründung.

Immigrations-Screening: Section-702-Daten dürfen nun zur Überprüfung von Einwanderern und Asylsuchenden verwendet werden.

Was der RISAA nicht enthält: eine Pflicht zum richterlichen Durchsuchungsbefehl für Backdoor Searches. Ein entsprechender Änderungsantrag scheiterte im Repräsentantenhaus mit einem Gleichstand von 212 zu 212 Stimmen.

Die einzige gute Nachricht: Der RISAA verlängerte Section 702 nur um zwei Jahre. Am 20. April 2026 läuft das Gesetz aus. Es sei denn, der Kongress verlängert es erneut.

FISA Section 702 und die DSGVO: Ein unlösbarer Konflikt

Hier schließt sich der Kreis zu unserem CLOUD-Act-Artikel. Denn während der CLOUD Act es US-Behörden ermöglicht, gezielt Daten von US-Unternehmen anzufordern, geht Section 702 noch viel weiter: Es erlaubt die massenhafte, programmatische Erfassung von Kommunikationsdaten – ohne dass einzelne Ziele gerichtlich genehmigt werden müssen.

Der Europäische Gerichtshof (EuGH) hat in seinem Schrems-II-Urteil vom Juli 2020 unmissverständlich festgestellt, dass Section 702 nicht mit den Grundrechten der EU vereinbar ist. Der Gerichtshof stellte insbesondere fest, dass Section 702 „keinerlei Beschränkungen der damit übertragenen Überwachungsbefugnisse oder Garantien für Nicht-US-Bürger" enthält, die potenziell betroffen sind. Auch das Presidential Policy Directive 28 (PPD-28), das gewisse Einschränkungen für die Überwachung von Nicht-US-Bürgern vorschreibt, wurde vom EuGH als unzureichend bewertet.

Das hat direkte Konsequenzen für europäische Unternehmen. Wenn ihr personenbezogene Daten eurer Kunden, Mitarbeiter oder Geschäftspartner über US-Dienste verarbeitet – sei es Microsoft 365, Google Workspace, AWS oder Salesforce –, dann sind diese Daten potenziell der Überwachung durch Section 702 ausgesetzt. Und das steht in direktem Widerspruch zur DSGVO, die einen „gleichwertigen Schutz" bei Datentransfers in Drittländer verlangt.

Das Trans-Atlantic Data Privacy Framework (TADPF), das Nachfolgeabkommen des gescheiterten Privacy Shield, steht bereits vor dem nächsten juristischen Angriff durch Max Schrems und noyb. Der Datenschutzaktivist hat darauf hingewiesen, dass die tatsächlichen Überwachungsgesetze der USA – allen voran Section 702 – sich durch das Framework nicht geändert haben. Seine Einschätzung: Das TADPF wird denselben Weg gehen wie Safe Harbor und Privacy Shield.

CLOUD Act + Section 702: Die doppelte Bedrohung

Um die Tragweite zu verstehen, müsst ihr den CLOUD Act und Section 702 zusammen betrachten:

Zusammen bilden diese beiden Gesetze ein lückenloses System: Der CLOUD Act gewährt den Zugriff auf gespeicherte Daten bei US-Unternehmen. Section 702 erlaubt das massenhafte Abfangen von Kommunikationen in Echtzeit. Egal ob eure Daten auf einem Microsoft-Server in Frankfurt liegen oder eure E-Mail über ein US-Backbone geroutet wird – die US-Regierung hat einen Weg, darauf zuzugreifen.

Die Aufsicht bröckelt

Selbst die ohnehin schwachen Kontrollmechanismen werden zunehmend ausgehöhlt. Das Privacy and Civil Liberties Oversight Board (PCLOB), das als zentrale Aufsichtsinstanz die Einhaltung der Bürgerrechte bei Überwachungsprogrammen überprüfen soll, wurde Anfang 2025 faktisch handlungsunfähig gemacht. Die demokratischen Mitglieder wurden entlassen, das Gremium besteht nun aus einem einzigen Teilzeit-Mitglied. Gleichzeitig wurde das Office of Internal Auditing des FBI – im Jahr 2020 eigens geschaffen, um Missbrauch zu verhindern – aufgelöst.

Das bedeutet: Die Mechanismen, die Missbrauch verhindern sollen, werden gerade systematisch abgebaut – während die Überwachungsbefugnisse gleichzeitig ausgeweitet werden.

Was ihr tun könnt: Praktische Schritte

Angesichts dieser Situation gibt es für europäische Privatpersonen und Unternehmen nur eine logische Konsequenz: Reduziert eure Abhängigkeit von US-Infrastruktur und US-Software.

Für eure Kommunikation: Signal oder andere Ende-zu-Ende-verschlüsselte Messenger sind unverzichtbar. Beachtet jedoch: Der EuGH hat angemerkt, dass US-Behörden unter Section 702 theoretisch auch kryptographische Schlüssel von US-Unternehmen anfordern könnten. Deshalb sind europäische Alternativen wie Threema oder Matrix/Element vorzuziehen.

Für eure Daten: Self-Hosting mit europäischer Software – etwa Nextcloud auf europäischen Servern – entzieht eure Daten vollständig der US-Jurisdiktion. Wie wir in unserem CLOUD-Act-Artikel erklärt haben: Entscheidend ist nicht, wo die Daten liegen, sondern wer sie kontrolliert. Eine selbst gehostete Lösung bei einem europäischen Anbieter ist der sicherste Weg.

Für eure E-Mails: Europäische E-Mail-Anbieter wie Tuta (ehemals Tutanota) oder Proton Mail unterliegen nicht der US-Jurisdiktion und bieten Ende-zu-Ende-Verschlüsselung.

Für euer Unternehmen: Führt eine Datentransfer-Folgenabschätzung (Transfer Impact Assessment) durch. Prüft, welche eurer Dienste US-Unternehmen sind oder Daten über US-Infrastruktur routen. Und dokumentiert diese Risiken – nicht nur für die DSGVO-Compliance, sondern für das Vertrauen eurer Kunden.

Fazit: Die Uhr tickt

Section 702 läuft am 20. April 2026 aus. Die nächsten Monate werden zeigen, ob der US-Kongress endlich grundlegende Reformen verabschiedet – etwa eine Pflicht zum richterlichen Durchsuchungsbefehl für den Zugriff auf Kommunikationen von US-Bürgern – oder ob das Gesetz erneut verlängert oder sogar ausgeweitet wird.

Aber selbst wenn Section 702 reformiert würde: Für europäische Bürger ändert sich wenig. Die Debatte in Washington dreht sich ausschließlich um die Rechte von US-Bürgern. Nicht-US-Bürger haben unter Section 702 keinerlei Schutz – und daran wird sich auch durch Reformen nichts ändern.

Die einzige Lösung für Europäer liegt nicht in Washington. Sie liegt in unseren eigenen Händen: in der konsequenten Nutzung eigener Infrastruktur, selbst gehosteter OpenSource Software und europäischer Dienste die sich dem Datenschutz gewidmet haben. Digitale Souveränität ist kein Luxus – sie ist die logische Antwort auf ein Überwachungssystem, das uns als Europäer ganz bewusst ohne jeden Rechtsschutz lässt.

Quellen und weiterführende Links

1. Brennan Center for Justice: „Section 702 of the Foreign Intelligence Surveillance Act (FISA): A Resource Page" – https://www.brennancenter.org/our-work/research-reports/section-702-foreign-intelligence-surveillance-act-fisa-resource-page
2. Electronic Frontier Foundation (EFF): „Upstream vs. PRISM" – https://www.eff.org/pages/upstream-prism
3. Congressional Research Service: „FISA Section 702 and the 2024 Reforming Intelligence and Securing America Act" – https://www.congress.gov/crs-product/R48592
4. EFF: „U.S. Senate and Biden Administration Shamefully Renew and Expand FISA Section 702" – https://www.eff.org/deeplinks/2024/04/us-senate-and-biden-administration-shamefully-renew-and-expand-fisa-section-702-0
5. Center for Democracy and Technology (CDT): „Four Reasons FISA 702 Still Needs a Warrant Rule for US Person Queries" – https://cdt.org/insights/four-reasons-fisa-702-still-needs-a-warrant-rule-for-us-person-queries/
6. Just Security: „Court Says Warrant Needed for U.S. Person Queries of FISA Section 702 Data" – https://www.justsecurity.org/106895/warrant-needed-fisa-section-702/
7. Electronic Privacy Information Center (EPIC): „Reforming 702: End Warrantless Backdoor Searches" – https://epic.org/reforming-702-end-warrantless-backdoor-searches/
8. Norton Rose Fulbright: „Schrems II landmark ruling: A detailed analysis" – https://www.nortonrosefulbright.com/en-us/knowledge/publications/ad5f304c/schrems-ii-landmark-ruling-a-detailed-analysis
9. EPIC v. DOJ – PRISM: Hintergründe zum PRISM-Programm – https://epic.org/documents/epic-v-doj-prism/
10. Cybersecurity Magazine: „FISA – A Catalyst for Europe's Cybersecurity Sovereignty" – https://cybersecurity-magazine.com/fisa-a-catalyst-for-europes-cybersecurity-sovereignty/
11. Federalist Society: „Reforming Section 702: Should the FBI Require a Warrant?" – https://fedsoc.org/briefcase/reforming-section-702-should-the-fbi-require-a-warrant-to-search-its-database-for-the-communications-of-us-persons
12. Information Technology Industry Council (ITI): „Expansion of FISA Electronic Communications Service Provider Definition Must Be Removed" – https://www.itic.org/news-events/techwonk-blog/expansion-of-fisa-electronic-communications-service-provider-definition-must-be-removed
13. Fieldfisher: „US surveillance: s702 FISA, EO 12333, PRISM and UPSTREAM" – https://www.fieldfisher.com/en/insights/us-surveillance-s702-fisa-eo-12333-prism-and-ups
14. State of Surveillance: „Section 702: The Law That Lets Feds Search Your Messages Without a Warrant" – https://stateofsurveillance.org/articles/government/section-702-fisa-warrantless-surveillance/

The post FISA Section 702: Das unsichtbare Netz der US-Massenüberwachung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Linux bietet mit Swap und zRAM sehr effektive Werkzeuge, um genau solche Situationen deutlich zu entschärfen. Richtig eingerichtet sorgen sie dafür, dass das System stabil bleibt, weniger einfriert und sich insgesamt flüssiger anfühlt – selbst bei knappen RAM-Ressourcen.

Dieses Tutorial erklärt:

• was Swap und zRAM sind
• worin der Unterschied liegt
• warum die Kombination sinnvoll ist
• wie man beides korrekt einrichtet
• wie man überprüft, ob alles richtig funktioniert

Das Ganze ist bewusst einsteigerfreundlich, aber technisch korrekt gehalten.

Was ist Swap

Swap ist Auslagerungsspeicher. Wenn der physische Arbeitsspeicher (RAM) knapp wird, kann Linux Speicherbereiche auf ein langsameres Medium auslagern – meist eine SSD oder HDD.

Vorteile von Swap

• verhindert Abstürze durch Speichermangel (OOM-Killer)
• sorgt dafür, dass das System weiterläuft
• ideal als Sicherheitsnetz

Nachteile von Swap

• deutlich langsamer als RAM
• kann bei starker Nutzung zu Rucklern führen

Swap ist wichtig, aber allein nicht optimal für Performance.

Was ist zRAM

zRAM ist komprimierter Arbeitsspeicher.

Dabei wird ein Teil des RAMs als komprimiertes Blockgerät genutzt. Daten werden also nicht auf die Festplatte, sondern komprimiert im RAM selbst abgelegt.

Vorteile von zRAM

• extrem schnell (bleibt im RAM)
• sehr gut komprimierbar (oft 1.5–2.5×)
• ideal für inaktive Speicherbereiche
• reduziert SSD-Swap massiv

Nachteile von zRAM

• benötigt etwas CPU-Leistung
• kann keinen echten RAM ersetzen

zRAM ist kein Ersatz für RAM, aber ein sehr effizienter Puffer.

Warum Swap UND zRAM kombinieren

Die beste Lösung ist eine zweistufige Speicherstrategie:

1. zRAM als schneller, komprimierter Zwischenspeicher
2. klassischer Swap als Notfallreserve

Linux nutzt automatisch zuerst den Swap mit der höheren Priorität – also zRAM – und greift nur im Ernstfall auf die SSD zurück.

Ergebnis:

• weniger Freezes
• stabileres Multitasking
• deutlich bessere Reaktionsfähigkeit

Schritt 1: Vorhandenen Swap prüfen

swapon --show

oder:

free -h

Wenn kein Swap vorhanden ist oder ihr neu starten wollt, geht es weiter mit Schritt 2. Solltet ihr bereits eine Swap Partition haben, überspringt Schritt 2, und macht weiter mit Schritt 3.

Schritt 2: Swapfile anlegen (Beispiel: 4 GB)

Gebt diese Befehle einzeln in die Konsole ein:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Danach dauerhaft aktivieren in der fstab Datei:

sudo nano /etc/fstab

Eintrag hinzufügen:

/swapfile none swap sw 0 0

Speichern mit strg+o und beenden mit strg-x

Schritt 3: zRAM installieren

Unter Ubuntu, KDE Neon und ähnlichen Debian Systemen:

sudo apt install zram-tools

Konfiguration öffnen:

sudo nano /etc/default/zramswap

Empfohlene Grundeinstellung am Ende der Datei setzen:

ENABLED=true
PERCENT=40
PRIORITY=100

Erklärung:

• PERCENT=40 → 40 % des RAMs als zRAM
• PRIORITY=100 → zRAM wird vor dem Swap genutzt

Dienst neu starten:

sudo systemctl restart zramswap

Schritt 4: Swappiness sinnvoll setzen

Swappiness steuert, wie früh Linux Swap nutzt, sollte der Arbeitspeicher eine bestimmte Auslastung erreichen.

Empfehlung für Desktop + wenig RAM:

sudo sysctl vm.swappiness=80

Dauerhaft:

sudo nano /etc/sysctl.conf

Eintrag:

vm.swappiness=80

Danach die Einstellungen mit:

sudo sysctl -p

direkt aktivieren

Schritt 5: Überprüfen, ob alles korrekt läuft

Swap-Status anzeigen

swapon --show

Erwartetes Ergebnis:

• zRAM mit hoher Priorität
• Swapfile mit niedriger Priorität

/dev/zram0

• 6 GB zRAM → passt zu PERCENT=40
• PRIO 100 → wird immer zuerst benutzt
• USED 0B → aktuell genug RAM, kein Druck

/swapfile

• 4 GB SSD-Swap
• PRIO -2 → klassischer Fallback
• wird erst benutzt, wenn zRAM voll ist

Genau die richtige Reihenfolge, die Einstellungen sind korrekt gesetzt.

Speicherverhalten beobachten

free -h

oder live:

watch -n 1 swapon --show

Gesundes Verhalten:

• zRAM wird genutzt
• SSD-Swap bleibt möglichst leer
• System bleibt bedienbar

Typische Empfehlungen nach RAM-Größe

4–8 GB RAM

• zRAM: 50 %
• Swapfile: 2–4 GB

16 GB RAM

• zRAM: 30–40 %
• Swapfile: 4–8 GB

32 GB RAM

• zRAM: optional
• Swapfile: klein oder nur als Fallback

Fazit

Swap und zRAM sind keine Notlösungen, sondern bewusst entwickelte Werkzeuge im Linux-Kernel.

Richtig kombiniert sorgen sie für:

• mehr Stabilität
• weniger Einfrieren
• bessere Alltagstauglichkeit

Gerade auf Systemen mit wenig RAM ist diese Konfiguration oft der größte Performance-Gewinn ohne neue Hardware.

Wenn trotz zRAM und Swap dauerhaft alles ausgelastet ist, gilt trotzdem: Kein Tuning ersetzt fehlenden Arbeitsspeicher. Aber bis zu diesem Punkt holt diese Methode das Maximum aus eurem System heraus.

The post Mehr Leistung bei wenig RAM: Swap & zRAM unter Linux appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitung

Sichert zunächst eure wichtigen Daten. Das sollte ohnehin regelmäßig geschehen, aber vor einem Major-Upgrade ist es besonders ratsam.

Aktualisiert das System auf den neuesten Stand, entweder über die integrierte Updateverwaltung:

Oder über das Terminal mit den Befehlen:

sudo apt update
sudo apt full-upgrade

Startet das System neu nachdem alles geupdated wurde.

sudo reboot

Methode 1: GUI-Upgrader (Desktop)

Öffnet die Anwendung Software-Aktualisierung (oder Update Manager). Ubuntu sollte euch aber auch automatisch mitteilen, dass eine neue Version (24.04) verfügbar ist.

Klickt auf System jetzt aktualisieren und folgt dem Assistent. Das System wird dann alle notwendigen Schritte automatisch ausführen. Das kann eine Weile dauern.

Falls ihr nicht direkt informiert werdet, dass eine Systemaktualisierung bereit stellt, bekommt ihr die Meldung mit einem Klick auf die Aktuliasierungsverwaltung.

Klickt in diesem Falle auf Aktualisieren...

Hier bekommt die Veröffentlichungshinweise, lest diese durch, falls interessiert.

Klickt als nächstes auf System aktualisieren.

Das System beginnt mit den Vorbereitungen der Aktualisierung und leitet alle nötigen Schritte ein.

Danach werdet ihr nochmals informiert, was alles geupdated wird, und danach gehts weiter mit der eigentlichen Aktualisierung:

Während des Upgrades informiert euch Ubuntu, das einige Pakete, hier zum Beispiel Thunderbird zukünftig nur noch als Snap Paket erhältlich ist, und zwingt euch unfreiweilig in ihr proprietäres Snap Ökosystem.

Bestätigt mit Weiter.

Falls ihr individuelle Konfigurationen an bestimmten Systemdateien getätigt habt, wird Ubuntu euch fragen, was mit diesen geschehen soll:

Klickt auf Beibehalten, wenn ihr individuelle Konfigurationen übernehmen wollt, oder Ersetzen falls ihr nie was an diesen Dateien verändert habt.

Anschliessend werdet ihr gefragt, ob ihr die veralteten Pakete entfernen wollt, der Ordnung halber entfernt ihr diese natürlich. Falls eurer Rechner nicht von 2005 sein sollte, geht das natürlich nicht mehrere Stunden.

Nach dem Upgrade startet ihr System neu und ihr seid nun auf Ubuntu 24.04 LTS.

Methode 2: Terminal mit do-release-upgrade

Diese Methode ist für diejenigen, die gerne im Terminal arbeiten oder die Kenntnisse darin vertiefen möchten. Sie funktioniert sowohl auf Desktop- als auch auf Server-Systemen.

Öffnet ein Terminal und gebt Folgendes ein:

sudo do-release-upgrade

Das System prüft automatisch, ob ein Upgrade verfügbar ist. Wenn ja, werden euch die Changelog und Upgrade-Details angezeigt.

Bestätigt mit y (yes), um fortzufahren:

Do you want to start the upgrade? [Y/n]

Das Upgrade lädt nun Pakete herunter und aktualisiert sie. Bei Rückfragen zu Konfigurationsdateien (z.B. von SSH oder anderen Services) werden euch Optionen angeboten:

• keep – Behaltet eure aktuelle Konfiguration
• install – Nutzt die neue Konfiguration von Ubuntu
• see diff – Zeigt die Unterschiede an

Für die meisten Nutzer ist es sicher, keep (N) zu wählen, wenn ihr Anpassungen gemacht habt.

Nach Abschluss werden alte, nicht mehr benötigte Pakete entfernt. Das System fordert euch auf, neu zu starten:

sudo reboot

Nach dem Neustart seid ihr auf Ubuntu 24.04.

Überprüfung nach dem Upgrade

Prüft die Ubuntu-Version:

lsb_release -a

Das sollte anzeigen:

Release: 24.04
Codename: noble

Bereinigt noch alte Paketdateien:

sudo apt autoremove
sudo apt autoclean

Troubleshooting: Was kann schiefgehen?

do-release-upgrade findet keine neue Version

Das passiert, wenn das System nicht auf dem neuesten Stand ist. Versucht:

sudo do-release-upgrade -d

Das -d erzwingt das Upgrade auf die nächste verfügbare Version.

Falls immer noch nichts passiert, prüft eure Repositories:

cat /etc/apt/sources.list

Achtet darauf, dass keine exotischen PPAs (Personal Package Archives) aktiviert sind, die das Upgrade blockieren.

Paketkonflikte während des Upgrades

Das Terminal zeigt euch dann eine Frage zu Konfigurationsdateien. Nutzt see diff, um zu prüfen, was sich ändert. Im Zweifel: keep (N) wählen, um eure Einstellungen zu behalten.

Das System bricht während des Upgrades ab

Falls das Internet unterbricht oder etwas anderes schiefgeht, könnt ihr das Upgrade fortsetzen:

sudo do-release-upgrade

Das erkennt den unvollendeten Prozess und setzt fort.

Abhängigkeitsprobleme nach dem Upgrade

Falls das System nicht vollständig aktualisiert wurde, versucht:

sudo apt install -f
sudo apt full-upgrade

Das -f repariert unterbrochene Installationen.

PPAs verursachen Probleme

Manchmal blockieren externe PPAs (z.B. für proprietary Software) das Upgrade. Ihr könnt sie deaktivieren:

sudo add-apt-repository --remove ppa:paketname/ppa

Oder alle auf einmal mit ppa-purge:

sudo apt install ppa-purge
sudo ppa-purge ppa:paketname/ppa

Nach dem Entfernen könnt ihr es erneut versuchen:

sudo do-release-upgrade

Desktop-Umgebung (GNOME/KDE) funktioniert nicht

Falls euer Desktop nach dem Upgrade nicht mehr startet, versucht:

sudo apt install --reinstall ubuntu-desktop
# oder für KDE:
sudo apt install --reinstall kubuntu-desktop

Meldet euch ab, wählt beim Login die richtige Umgebung und meldet euch wieder an.

Netzwerk funktioniert nach dem Upgrade nicht

Das ist selten, kann aber passieren. Prüft die Netzwerk-Manager-Konfiguration:

sudo systemctl restart networking

Oder für systemd-based Systeme:

sudo systemctl restart systemd-networkd

Fazit

Das Upgrade von 22.04 auf 24.04 ist ein relativ unkomplizierter Prozess. Nutzt die Terminal-Methode mit do-release-upgrade – sie ist transparenter, zuverlässiger und funktioniert überall gleich gut, ob auf Desktop oder Server. Mit etwas Geduld und den richtigen Antworten zu Konfigurationsfragen ist das System schnell auf dem neuesten Stand.

Viel Erfolg beim Upgrade!

The post Ubuntu 22.04 auf 24.04 upgraden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Mit Immich steht dir ab sofort ein moderner, leistungsfähiger und datenschutzfreundlicher Foto- und Video-Dienst zur Verfügung. Der Service richtet sich an alle, die ihre Erinnerungen sicher speichern, komfortabel verwalten und jederzeit abrufen möchten – ohne Abhängigkeit von kommerziellen Cloud-Anbietern.

Im Gegensatz zu bekannten Plattformen wie Google Photos oder iCloud bleibt bei Immich die volle Kontrolle über deine Daten erhalten. Es gibt kein Tracking, keine Profilbildung, keine Weitergabe an Werbenetzwerke. Deine Fotos und Videos werden ausschließlich innerhalb dieses Dienstes verarbeitet.

📸 Automatische Backups von Smartphone & Desktop

Immich bietet mobile Apps für Android und iOS, mit denen Fotos und Videos automatisch gesichert werden können. Neue Aufnahmen landen zuverlässig im persönlichen Archiv, ohne manuelles Hochladen oder komplizierte Workflows.
Zusätzlich steht eine Weboberfläche zur Verfügung, über die du deine Mediensammlung bequem vom Desktop aus verwalten kannst.

🗂️ Übersichtliche Organisation & intelligente Suche

Alle Medien werden automatisch nach Datum, Aufnahmezeit und Metadaten sortiert. Große Sammlungen bleiben übersichtlich, auch über Jahre hinweg.
Dank integrierter Analysefunktionen kannst du deine Fotos und Videos gezielt durchsuchen – etwa nach Motiven, Orten oder Personen – ohne dass Inhalte an externe Dienste gesendet werden.

👥 Alben & Teilen – kontrolliert und bewusst

Du kannst Alben erstellen und gezielt freigeben, etwa für Familie oder Freunde. Dabei behältst du jederzeit die Kontrolle darüber, wer was sehen darf. Keine öffentlichen Profile, keine unfreiwillige Sichtbarkeit, kein algorithmisches Ranking.

🔐 Datenschutz als Grundprinzip

Immich ist konsequent auf Privatsphäre ausgelegt:

• kein Zwang zu externen Accounts
• kein Tracking durch Drittanbieter
• keine Werbung
• keine Analyse zu Marketingzwecken

Der Dienst eignet sich besonders für Nutzer, die ihre persönlichen Erinnerungen nicht an große Konzerne auslagern möchten.

🌍 Zugriff von überall

Ob Smartphone, Tablet oder Desktop – deine Fotos und Videos sind jederzeit verfügbar. Die Oberfläche ist modern, schnell und auf den täglichen Gebrauch ausgelegt, auch bei sehr großen Mediensammlungen.

✅ Für wen ist Immich gedacht?

• für alle, die ihre Fotos sicher und langfristig speichern möchten
• für Familien mit gemeinsamen Fotoalben
• für datenschutzbewusste Nutzer
• für alle, die eine echte Alternative zu kommerziellen Cloud-Galerien suchen

3GB Speicher Gratis für alle

Deine persönliche Fotocloud bietet dir 3GB Speicher für deine Fotos und Videos.

The post Immich – Private Foto- & Video-Cloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wanderer ist ein offenes, leistungsfähiges Tool, mit dem du deine Aktivitäten rund um Trails, Pfade und Outdoor-Abenteuer zentral verwaltest. Die Oberfläche ist intuitiv gestaltet, sodass sowohl Hobby-Wanderer als auch erfahrene Outdoor-Communities ihre Touren einfach dokumentieren und planen können. (wanderer Documentation)

🧭 Was du mit Wanderer machen kannst

• 📍 GPS-Tracks hochladen – Lade GPX- oder TCX-Dateien hoch und speichere deine aufgezeichneten Wanderungen inklusive aller relevanten Infos wie Distanz, Höhenmeter oder Dauer. (wanderer Documentation)
• 🗺️ Routen erstellen & planen – Zeichne neue Trails direkt auf der Karte oder nutze moderne Routing-Tools zur Planung deiner nächsten Strecke. (wanderer Documentation)
• 📋 Metadaten hinzufügen – Ergänze Beschreibungen, Schwierigkeitsgrad, Geländeart, Tags oder Regionen zu deinen Trails für bessere Übersicht und Suche. (wanderer Documentation)
• 🔍 Trail-Sammlung durchsuchen – Organisiere, filtere und finde Routen schnell über Suchfunktionen und Kategorien. (wanderer Documentation)
• 🌄 Fotos & Erinnerungen integrieren – Mache deine Trails lebendig mit Fotos, Notizen oder Wegpunkten. (wanderer Documentation)

🤝 Soziale Funktionen & Fediverse-Integration

Wanderer bietet optionale soziale Features, damit du dich mit anderen Entdeckern vernetzen kannst. Du kannst:

• 🌐 anderen Nutzern folgen
• ❤️ Trails liken
• 💬 Kommentare hinterlassen
• 📬 Benachrichtigungen erhalten

Dank Federation (über ActivityPub) ist Wanderer außerdem kompatibel mit anderen föderierten Plattformen, sodass Interaktionen über Instanzgrenzen hinweg möglich sind – für eine vernetzte Outdoor-Community. (wanderer Documentation)

💡 Warum Wanderer nutzen?

• 🏞️ Ideal für Outdoor-Fans – perfekt für Wanderer, Trailrunner, Radfahrer oder alle, die draußen aktiv sind.
• 🔐 Datenschutz steht im Mittelpunkt – keine Werbung, kein Tracking, keine Weitergabe deiner Daten.
• 🌍 Einfache Nutzung – intuitiv bedienbar auf Desktop wie Mobilgeräten.
• 📈 Deine Abenteuer, dein Archiv – alles an einem Ort, übersichtlich gespeichert und leicht zugänglich.

Mit Wanderer geben wir dir ein mächtiges Werkzeug an die Hand, um deine Outdoor-Erlebnisse zu planen, zu archivieren und mit anderen Abenteurern zu teilen – datenschutzfreundlich, frei und ohne externe Datenkraken.

Probier es aus: ➜ wanderer.yourdevice.ch

The post Wanderer – Outdoor-Trail-Hub appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitung

Bevor ihr startet, macht eine Sicherung eurer wichtigen Daten. Das sollte ohnehin regelmäßig geschehen, aber vor einem Major-Upgrade ist es besonders ratsam.

Aktualisiert zunächst das System auf den neuesten Stand von Bookworm:

sudo apt update
sudo apt full-upgrade

Nach diesen Befehlen kann es nötig sein, den Rechner neuzustarten – befolgt die Aufforderungen des Systems.

Die Repository-Quellen anpassen

Das Herzstück des Upgrades: Ihr müsst alle Verweise auf „bookworm" in eurer apt-Quellenliste in „trixie" umwandeln.

Öffnet die Datei mit einem Editor eurer Wahl:

sudo nano /etc/apt/sources.list

(Alternativ geht auch sudo vi /etc/apt/sources.list oder ein anderer Editor.)

Sucht nach Zeilen, die „bookworm" enthalten, und ersetzt diesen Begriff durch „trixie". Typischerweise sieht es vorher so aus:

deb http://deb.debian.org/debian bookworm main contrib non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware

Danach sollte es so aussehen:

deb http://deb.debian.org/debian trixie main contrib non-free-firmware
deb-src http://deb.debian.org/debian trixie main contrib non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free-firmware
deb-src http://security.debian.org/debian-security trixie-security main contrib non-free-firmware

Speichert die Datei (in nano: Strg+O, Enter, dann Strg+X).

Prüft auch, ob weitere sources-Listen vorhanden sind:

ls -la /etc/apt/sources.list.d/

Wenn dort .list oder .sources-Dateien sind, müsst ihr auch dort „bookworm" durch „trixie" ersetzen.

Das eigentliche Upgrade

Jetzt aktualisiert die Paketlisten:

sudo apt update

Führt einen Testlauf durch, um zu sehen, welche Pakete aktualisiert werden:

sudo apt full-upgrade --dry-run

Wenn alles gut aussieht, startet das echte Upgrade:

sudo apt full-upgrade

Das kann eine Weile dauern. Der Prozess lädt große Mengen an Daten herunter und aktualisiert hunderte von Paketen. Bei Rückfragen des Systems (z.B. zu Konfigurationsdateien) empfiehlt es sich, die Standardoptionen zu wählen, außer ihr habt spezifische Änderungen an Dateien vorgenommen.

Wählt hier einfach immer N (keep your currently-installed version), und bestätigt mit Enter.

Nach dem Upgrade

Startet den Rechner neu:

sudo reboot

Prüft nach dem Start, dass alles lädt:

uname -r

Das sollte euch einen Kernel mit „trixie" anzeigen.

Bereinigt alte Pakete:

sudo apt autoremove
sudo apt autoclean

Troubleshooting: Was kann schiefgehen?

Paketkonflikte während des Upgrades

Manchmal zeigt apt an, dass Pakete nicht installiert werden können, weil Abhängigkeiten fehlen. Versucht in diesem Fall:

sudo apt --fix-broken install

Oder wartet mit dem Upgrade auf ein bestimmtes Paket, bis Abhängigkeiten geklärt sind. Das ist selten nötig, kommt aber vor.

„Unmet dependencies" Fehlermeldung

Falls apt weigert sich weiterzumachen, versucht:

sudo apt install -f

Das versucht, fehlende Abhängigkeiten automatisch zu beheben.

Einzelne Pakete verursachen Probleme

In seltenen Fällen kann ein einzelnes Paket das Upgrade blockieren. Ihr könnt es temporär „halten", bis der Rest aktualisiert ist:

sudo apt-mark hold paketname

Und später wieder freigeben:

sudo apt-mark unhold paketname

Das System startet nicht nach dem Upgrade

Das ist sehr selten. Falls es passiert:

• Startet von einem Debian Live USB
• Mounted die Root-Partition
• Repariert GRUB mit sudo grub-install /dev/sda (oder eure entsprechende Festplatte)

Desktop-Umgebung ist kaputt

Falls X11 oder euer Desktop nicht mehr startet, versucht:

sudo apt install --reinstall xserver-xorg

Oder, wenn ihr GNOME/KDE nutzt:

sudo apt install --reinstall gnome-shell
# oder
sudo apt install --reinstall kde-full

Fazit

Das Upgrade von Bookworm auf Trixie ist ein geradliniger Prozess, wenn ihr die Repositories korrekt austauscht. Mit ein paar Terminal-Befehlen und etwas Geduld ist das System schnell auf dem neuesten Stand. Die fehlende GUI ist kein Hindernis – im Gegenteil: Ihr habt volle Kontrolle über den Prozess und könnt jederzeit sehen, was passiert.

Viel Erfolg beim Upgrade!

The post Debian 12 Bookworm auf Trixie 13 upgraden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Ihr könnt die entsprechenden Schritte je nach eurer aktuellen Mint-Version und Anforderung befolgen.

Der Leitfaden wurde mit den Schritten zum Upgrade auf Linux Mint 22 von Mint 21.3 erstellt. Linux Mint hat ein GUI-Programm zum Upgrade auf die neueste Version.

Die gleichen Schritte gelten im übrigen für Benutzer, die von Mint 20.3 auf Mint 21 upgraden möchten (welches bis 2025 unterstützt wird).

Das solltet ihr vor dem Upgrade auf Linux Mint 22 wissen

Bevor ihr zu Linux Mint 22 upgraded, solltet ihr Folgendes beachten:

• Benötigt ihr das Upgrade wirklich? Linux Mint 21.x wird noch bis 2027 unterstützt.
• Ihr benötigt eine gute Internetverbindung, um Updates von über 1 GB herunterzuladen.
• Das Upgrade kann basierend auf eurer Internetgeschwindigkeit einige Stunden dauern. Ihr müsst geduldig sein.
• Es ist eine gute Idee, einen Live-USB von Linux Mint 22 zu erstellen und ihn in einer Live-Sitzung auszuprobieren, um zu sehen, ob er mit eurer Hardware kompatibel ist und alles bestens funktioniert. In der Regel wird ältere Hardware mit neueren Mint Versionen noch besser unterstützt.
• Obwohl Upgrades meist sicher sind, sind sie nicht immer zu 100% fehlerfrei. Ihr solltet System-Snapshots und angemessene Sicherungen haben.
• Ihr könnt nur von Linux Mint 21.3 Cinnamon, Xfce und MATE zu Linux Mint 22 upgraden. Überprüft zuerst eure Linux-Mint-Version. Wenn ihr Linux Mint 21.2 oder 21.1 verwendet, müsst ihr zuerst vom Update Manager auf 21.3 upgraden. Wenn ihr Linux Mint 20 verwendet, rate ich euch, eine Neuinstallation durchzuführen, anstatt auf mehrere Mint-Versionen zu upgraden.

Sobald ihr wisst, was ihr tun werdet, schauen wir uns an, wie ihr zu Linux Mint 22 upgraded.

Upgrade auf Linux Mint 22 von 21.3

Überprüft eure Linux-Mint-Version und stellt sicher, dass ihr Mint 21.3 verwendet.

lsb_release -a

Ihr könnt nicht von Mint 21.1 oder 21.2 zu Mint 22 upgraden. Stellt sicher, dass ihr das System auf Mint 21.3 aktualisiert habt, bevor ihr euch an das Upgrade macht.

Schritt 1: Aktualisiert euer System durch Installation aller verfügbaren Updates

Startet als erstes den Update Manager mit Menu → sucht nach Update → geht auf die Aktualisierungsverwaltung.

Überprüft, ob Package-Updates verfügbar sind. Wenn ja, installiert zuerst alle Software-Updates.

Die Meldung „Euer System ist aktuell" wird im Software-Manager angezeigt.

Ihr könnt auch diesen Befehl im Terminal für diesen Schritt verwenden:

sudo apt update && sudo apt upgrade -y

Führt auf jeden Fall ein Neustart des System durchs sobald ihr alles geupdated habt.

Schritt 2: Erstellt eine Sicherung eurer Dateien auf einer externen Festplatte (Optional, aber empfohlen)

Timeshift ist ein gutes Programm zum Erstellen von System-Snapshots, aber es ist nicht das unkomplizierteste Programm für eure Dokumente, Bilder und andere persönliche Dateien, wenn man mal schnell ein Backup durchführen will. Ich rate euch, eine Timeshift Sicherung, oder eine manuelle Sicherung auf einer externen Festplatte zu erstellen. Dies dient einfach der Datensicherheit.

Wenn ich sage, eine Sicherung auf einer externen Festplatte zu erstellen, meine ich einfach, eure Ordner Bilder, Dokumente, Downloads und Videos auf einen externen USB-Stick zu kopieren und einzufügen.

Wenn ihr keine Festplatte dieser Größe habt, kopiert zumindest die wichtigsten Dateien, auf die ihr nicht verzichten könnt.

Schritt 3: Installiert das Upgrade-Programm

Jetzt, da euer System aktualisiert ist, seid ihr bereit, zu Linux Mint 22 zu upgraden. Das Linux-Mint-Team stellt ein GUI-Programm namens mintupgrade zum Upgrade von Linux Mint 21.3 auf Linux Mint 22 zur Verfügung.

Ihr könnt dieses Programm mit dem folgenden Befehl installieren:

sudo apt install mintupgrade

Schritt 4: Startet das GUI-Programm vom Terminal

Ihr könnt das neue GUI-Programm nicht im App-Menü aufgelistet finden. Zum Starten müsst ihr den folgenden Befehl im Terminal eingeben:

sudo mintupgrade

Dieses einfache, aber umfassende Programm führt euch durch den Upgrade-Prozess.

Es wird euch fragen, ob es eine Reihe von Tests durchführen darf, um euren Computer auf ein Upgrade vorzubereiten.

Eine Reihe von Tests wird durchgeführt, um den Computer auf das Upgrade vorzubereiten.

Nach diesen Anfangstests werden euch Timeshift-Sicherungen angefordert. Wenn ihr bereits eine Sicherung erstellt habt, seid ihr bereit.

Klickt auf Beheben, um ein aktuelles Timeshift Backup anzulegen.

Wenn ihr das Upgrade auf einer VM oder ähnlichem testet, benötigt ihr möglicherweise nicht den Timeshift-Snapshot. Klickt in diesem Fall auf das Hamburger-Menü oben rechts und wählt Einstellungen.

Im den Einstellungen der Aktualisierung oben rechts im Burgermenu, könnt ihr die Anforderung für Timeshift-Sicherung deaktivieren.

In den meisten Fällen solltet ihr das nicht tun. Eine aktive Sicherung ist während solcher Versionsupgrades notwendig.

Die meissten PPAs sind bereits für Ubuntu 24.04, und damit für Mint 22, verfügbar. Aber wenn ein PPA oder Repository für die neue Version nicht verfügbar ist, könnte dies den Upgrade-Prozess mit fehlerhaften Abhängigkeiten beeinflussen. Dies wird euch im Upgrade-Programm mitgeteilt. Dies wird aber zum heutigen Zeitpunkt eher weniger der Fall sein, da Linux Mint 22 bereits einige Zeit verfügbar ist. Trotzdem gehen wir auf die Fehlerbehebung während des Update Prozesses ein!

Hier zum Beispiel ist das Vim-PPA ist für Mint 22 nicht verfügbar

In diesem Beispiel habe ich die neueste Version von Vim über PPA verwendet. Dasselbe PPA wird nur bis Ubuntu Jammy Jellyfish (22.04) unterstützt, daher der Fehler, da Linux Mint 22 auf Noble Numbat (24.04) basiert.

Klickt auf Korrigieren und euch wird die Möglichkeit gegeben, die PPAs über Softwarequellen im Upgrade-Programm zu deaktivieren.

Da das PPA deaktiviert ist, wird das Paket „fremd", da die verfügbare Version aus dem Repository nicht mit den Versionen aus den Mint-Repositories übereinstimmt. Daher müsst ihr die Pakete auf eine Version herabstufen, die im Repository verfügbar ist. Klickt hier einfach auf Reparieren.

Jetzt beginnt Phase zwei. Hier werden nach einem Klick auf OK einige Tests durchgeführt und Pakete heruntergeladen.

Das Upgrade-Programm listet nun die Änderungen auf, die durchgeführt werden müssen.

Änderungen, die durchgeführt werden müssen, sind aufgelistet.

Nach Bestätigung mit OK wird das Programm mit dem Download der Pakete beginnen.

Phase drei: nach einem Klick auf OK wird mit dem Upgrade der Pakete begonnen.

Wenn ihr auf OK klickt, beginnt also das eigentliche Upgrade der Pakete.

Das System wird aktualisiert. Der Prozess dauert einige Zeit.

In einigen Fällen müssen während der Installation weitere Pakete herabgestuft werden, um Konflikte zu vermeiden. Klickt auf Beheben, um fortzufahren.

Mehr Pakete müssen herabgestuft werden, um den Upgrade-Prozess fortzusetzen:

Dies entfernt die weiteren inkompatiblen Pakete.

Nach Abschluss geht ihr zur Finalisierungsphase über.

Danach erhaltet ihr eine Benachrichtigung, dass das Upgrade abgeschlossen wurde.

Schließt das Upgrade-Programm und startet euer System neu, damit das Update wirksam wird.

Nach dem Neustart seid ihr im neuen Linux Mint 22 🎉

Seid ihr auf Linux Mint 22 umgestiegen?

Das Upgrade auf Mint 22 ist genauso einfach wie auf die vorherige Version. Und es wird nur noch besser.

Wenn ihr euch immer noch nicht entscheiden könnt, möchtet ihr vielleicht unsere Linux-Mint-22-Rezension vor dem Upgrade lesen.

Ich hoffe, ihr findet das Anleitung hilfreich. Seid ihr auf Linux Mint 21 umgestiegen oder habt ihr euch für eine Neuinstallation entschieden?

Falls ihr auf Probleme stoßt oder weitere Hilfe zum Upgrade-Prozess benötigt, könnt ihr gerne eine Frage im Kommentarbereich stellen.

Credits: itsfoss.com. Die Bilder mit dem schwarzen Hintergrund stammen von itsfoss.com da bei mir keine Fehler beim Updateprozess aufgetreten sind. Der Vollständigkeit halber, wollte ich diese Schritte aber inkludieren.

The post So upgradet ihr auf Linux Mint 22 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

AdventureLog ist eine moderne Plattform, um besuchte Orte, geplante Reisen und persönliche Erlebnisse übersichtlich zu organisieren. Alles passiert auf unserer eigenen Infrastruktur und unterliegt denselben Datenschutz-Grundsätzen wie unsere übrigen Dienste.

✈️ Was kannst du mit AdventureLog machen?

• 📍 Reisen und Orte dokumentieren
  Halte fest, wo du warst, wann du dort warst und was du erlebt hast – inklusive Notizen, Bewertungen und persönlichen Eindrücken.
• 🗺️ Interaktive Kartenansicht
  Deine Abenteuer werden übersichtlich auf einer Weltkarte dargestellt – ideal, um vergangene Reisen zu visualisieren oder zukünftige Ziele zu planen.
• 📅 Zukünftige Trips planen
  Plane Reisen im Voraus, erstelle Itineraries, füge Aktivitäten hinzu und behalte den Überblick über anstehende Abenteuer.
• 🧭 Chronologische Übersicht
  Alle Reisen werden zeitlich geordnet angezeigt – perfekt als persönliches Reisetagebuch.
• 🔗 Teilen, wenn du willst
  Einzelne Reisen oder Ansichten können optional per Link geteilt werden – komplett freiwillig und kontrolliert.

🔐 Fokus auf Datenschutz

AdventureLog kommt ohne externe Tracker, ohne Werbenetzwerke und ohne Profilbildung aus. Deine Daten bleiben bei uns und werden nicht für Analyse- oder Marketingzwecke missbraucht.
Du nutzt einen vollwertigen Reise-Service, ohne dich dafür gläsern machen zu müssen.

🌱 Für wen ist AdventureLog gedacht?

• Für Reisende, die ihre Erlebnisse digital festhalten möchten
• Für Nutzer, die ihre Reisen planen wollen, ohne Google-Dienste zu nutzen
• Für alle, die Wert auf Privatsphäre, Kontrolle und Transparenz legen

AdventureLog ergänzt unser bestehendes Angebot an freien und datenschutzfreundlichen Diensten und bietet dir eine echte Alternative zu kommerziellen Reise-Apps.

Zu AdventureLog gehts hier!

The post AdventureLog – Reisen & Erlebnisse appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Ratgeber erfahrt ihr, worauf es beim Kauf eines Linux Laptops ankommt, welche Vorteile euch erwarten und warum ein vorkonfiguriertes Gerät oft die bessere Wahl ist.

Warum einen Linux Laptop kaufen

Linux hat sich längst von der "Nerd-Distribution" zum ausgereiften Desktop-System entwickelt. Die Vorteile liegen auf der Hand:

Performance und Ressourcen: Linux läuft auch auf älterer Hardware flüssig. Wo Windows 11 mindestens 8 GB RAM verlangt, kommt Linux oft mit der Hälfte aus. Das bedeutet längere Akkulaufzeit und schnellere Reaktionszeiten – gerade bei Laptops ein entscheidender Vorteil.

Privatsphäre und Kontrolle: Keine Telemetrie, keine Zwangs-Updates, keine versteckten Datensammlungen. Ihr entscheidet, was auf eurem System läuft und welche Daten ihr teilt.

Kosten: Die meisten Linux-Distributionen sind kostenlos. Bei einem neuen Laptop spart ihr euch die Windows-Lizenz, die oft 100-150 CHF kostet. Auch Software ist meist Open Source und gratis verfügbar.

Noch unsicher, ob Linux das Richtige für euch ist? Hier erfahrt ihr mehr über die Gründe für den Umstieg.

Worauf beim Kauf eines Linux Laptops achten

Hardware-Kompatibilität ist entscheidend

Nicht jede Hardware funktioniert out-of-the-box mit Linux. Besonders kritisch sind:

• WLAN-Chips: Broadcom oder Mediatek bereiten oft Probleme, Intel und Atheros laufen meist problemlos
• Grafikkarten: NVIDIA benötigt proprietäre Treiber, AMD und Intel funktionieren nativ besser
• Touchpads und Fingerprint-Sensoren: Moderne Synaptics-Touchpads sind gut unterstützt, biometrische Sensoren oft nicht, Linux Mint 23 soll das aber ändern!

Mehr Details zur Hardware-Kompatibilität findet ihr in unserem ausführlichen Artikel zur benötigten Hardware.

Die richtige Distribution wählen

Mint, Ubuntu, Fedora, Mint, Pop!_OS – die Auswahl ist riesig. Für Einsteiger eignen sich besonders:

• Ubuntu/Linux Mint: Große Community, viele Tutorials, stabile Basis
• Fedora: Modern, aktuelle Software, guter Kompromiss
• Pop!_OS: Speziell für Laptops optimiert, NVIDIA-Support integriert

Nicht sicher, welches Linux zu euch passt? Nutzt unseren Linux Finder – ein interaktives Quiz, das basierend auf euren Anforderungen die perfekte Distribution empfiehlt.

Einen Überblick über alle gängigen Systeme bekommt ihr in unserem Betriebssystem-Vergleich.

ThinkPads: Die Klassiker für Linux-User

Wenn von Linux-Laptops die Rede ist, fallen fast immer ThinkPads. Die Lenovo-Serie hat sich über Jahrzehnte einen legendären Ruf in der Linux-Community erarbeitet – aus gutem Grund.

Warum ThinkPads so beliebt sind:

Hervorragende Hardware-Kompatibilität: Lenovo testet ThinkPads aktiv mit Linux-Distributionen. Treiber funktionieren out-of-the-box, keine Bastelei mit WLAN-Chips oder Touchpads.

Robuste Bauweise: ThinkPads sind für den Business-Einsatz konzipiert. Das bedeutet solide Verarbeitung, gute Tastatur und Langlebigkeit – wichtig, wenn ihr das Gerät täglich nutzt.

Riesige Community: Für nahezu jedes ThinkPad-Modell findet ihr Online-Dokumentation, Tipps und Support von anderen Linux-Usern.

Bei yourdevice.ch führen wir die ThinkPad E-Serie – solide Mittelklasse-Modelle, die das Beste aus beiden Welten bieten: ThinkPad-Qualität ohne Premium-Preis. Hier geht's zu unseren ThinkPad E14 und E16 Modellen.

Support und Garantie in der Schweiz

Ein oft unterschätzter Punkt: Kauft ihr einen Linux Laptop in der Schweiz, habt ihr lokalen Support und Garantie nach Schweizer Recht. Bei Import-Geräten aus dem Ausland müsst ihr bei Problemen oft aufwendig zurückschicken. Ausserdem verweigern Hersteller häufig den Support, sollte ein neueres Gerät defekt gehen, und ihr hattet darauf Linux installiert da das Gerät dann nicht mehr dem original Zustand entspricht. Bei uns ist Linux Originalzustand!

Vorkonfiguriert kaufen vs. selbst installieren

Technisch versierte User können natürlich jeden Laptop kaufen und Linux selbst installieren. Aber ist das wirklich die beste Lösung?

Vorteile vorkonfigurierter Linux Laptops:

Zeitersparnis: Die Installation dauert zwar nur 30-60 Minuten, aber Treiber konfigurieren, Updates einspielen, System absichern und Software installieren kostet schnell mehrere Stunden. Bei einem vorkonfigurierten System ist alles fertig eingerichtet.

Funktionierende Treiber: Alle Hardware-Komponenten sind getestet und funktionieren garantiert. Keine bösen Überraschungen mit nicht funktionierendem WLAN oder Touchpad.

Professionelle Einrichtung: Das System ist bereits mit sinnvollen Einstellungen konfiguriert, Updates sind richtig eingerichtet, und grundlegende Sicherheitsmaßnahmen sind implementiert.

Support bei Problemen: Wenn doch mal etwas nicht funktioniert, habt ihr einen Ansprechpartner, der das System kennt und helfen kann.

Linux vorher ausprobieren

Wer möchte, kann Linux über eine virtuelle Maschine vorher schnell und einfach ausprobieren. Das geht zum Beispiel über eine virtuelle Maschine, oder über die Installation von Linux auf einer externen SSD. So kann man sich vorher schon ein Bild machen, welches Linux am besten zu einem passt.

Linux im Alltag: Keine Kompromisse nötig

"Aber funktioniert mein Scanner?" – "Kann ich Office-Dokumente bearbeiten?" Ja und ja!

Office und Produktivität

Office auf Linux ist längst kein Problem mehr. LibreOffice bietet volle Kompatibilität mit Microsoft-Formaten. Für cloudbasiertes Arbeiten funktionieren Google Docs und Microsoft 365 im Browser einwandfrei.

E-Mail-Programme wie Thunderbird stehen Windows in nichts nach. Wer mehr Privatsphäre will, findet bei uns auch Matrix-basierte Chat-Lösungen.

Hardware-Peripherie

Scanner funktionieren unter Linux meist besser als unter Windows – dank des SANE-Projekts werden tausende Modelle unterstützt. Drucker, Webcams, externe Festplatten: Alles läuft in der Regel problemlos.

Software-Alternativen

Für fast jedes Windows-Programm gibt es eine Linux-Alternative. Unsere Übersicht zeigt euch die besten Alternativen.

Ist Linux kompliziert?

Kurze Antwort: Nein. Ihr müsst keine Terminal-Kenntnisse besitzen, um Linux zu nutzen. Moderne Distributionen sind so bedienbar wie Windows oder macOS.

Für den vollständigen Überblick: Unser Overall-Leitfaden für den Umstieg begleitet euch Schritt für Schritt.

Linux Laptops kaufen bei yourdevice.ch

Seit Jahren bieten wir bei yourdevice.ch vorkonfigurierte Linux Laptops in der Schweiz an. Aber wir sind mehr als nur ein Shop.

Freie Betriebssystem-Wahl

Ihr entscheidet, welches Linux auf eurem Laptop läuft. Ubuntu, Fedora, Mint, Pop!_OS – oder nutzt unseren Linux Finder, um die perfekte Distribution zu finden. Wir installieren und konfigurieren das System nach euren Wünschen.

Umfangreiche Knowledgebase

Mit über 340 Artikeln zu Linux, Netzwerk, Bitcoin und mehr bieten wir eine der umfassendsten deutschsprachigen Linux-Ressourcen. Egal ob Antiviren-Programme, Festplatten-Verschlüsselung oder alltägliche Fragen – ihr findet Antworten.

Exklusive Open-Source-Services

Als Kunde bei yourdevice.ch erhaltet ihr kostenlosen Zugang zu einer Vielzahl von Open-Source-Services:

Cloud & Zusammenarbeit:

• Nextcloud (10GB gratis für Kunden) – eure eigene Cloud, keine Google Drive Abhängigkeit
• Matrix Chatserver – verschlüsselte Kommunikation, WhatsApp-Alternative
• Jitsi Meet – Videokonferenzen ohne Zoom oder Teams
• Element Web – moderner Matrix-Client im Browser

Privatsphäre & Sicherheit:

• Vaultwarden – Passwort-Manager (Bitwarden-kompatibel)
• Trash Mail Service – Wegwerf-E-Mails für mehr Privatsphäre
• VPN-freundliche DNS-Server – keine Zensur, keine Tracking
• Clientseitige Datei-Verschlüsselung – eure Daten, eure Kontrolle

Kommunikation & Alternativen:

• WhatsApp Proxy Server – Zugriff in zensierten Ländern
• Alternative IMDB-Frontends – Filminfos ohne Werbung
• Multi-Translator – Übersetzungen ohne Big Tech

Tools & Entwicklung:

• Bitcoin Mining Pool – für die Krypto-Community
• Private Electrum Server – Bitcoin-Wallet-Backend
• Event Planner – gemeinsam Events organisieren
• Linkwarden – Bookmark-Manager
• Find My Device – Geräteortung mit Open Source

Alle Services sind für Kunden kostenlos und direkt über euer Konto von yourdevice.ch nutzbar und werden aktiv gewartet. Keine Werbung, keine Datensammlung, nur funktionierende Tools für euren Alltag.

Lokaler Support aus der Schweiz

Probleme? Fragen? Wir sprechen Deutsch und sind für euch da. Keine Hotline in Indien, kein Ticket-System, das tagelang dauert – echte Menschen mit Linux-Expertise helfen euch weiter.

Dualboot Systeme mit Windows

Seit ihr euch noch nicht ganz sicher bezüglich des Umstiegs und benötigt Windows parallel zur Linux? Auch das bieten wir an, bei Bedarf installieren wir Linux parallel zu Windows, so kann man für das Was laufen muss, Windows verwenden, und für den Umstieg und das kennen lernen Linux benutzen.

Bereit für den Umstieg?

Linux Laptops kaufen in der Schweiz war noch nie so einfach. Kombiniert Hardware, die funktioniert, mit einem Betriebssystem, das euch gehört, und einem Service-Paket, das euch unabhängig macht.

Entdeckt jetzt unsere Linux-Laptop-Auswahl oder nutzt unseren Linux Finder, um die perfekte Distribution zu finden.

Fragen? Schreibt uns – wir beraten euch gerne bei der Auswahl des richtigen Systems für eure Bedürfnisse.

The post Linux Laptop kaufen in der Schweiz: Kaufratgeber 2026 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was bedeutet das konkret für euch? Ihr glaubt, eure Windows-Festplatte sei verschlüsselt und sicher. Aber wenn Microsoft die Schlüssel in der Cloud speichert, können US-Behörden mit einem Durchsuchungsbefehl darauf zugreifen. Eure Verschlüsselung ist nur so sicher, wie das Unternehmen, das die Schlüssel verwaltet.

Microsoft bestätigte gegenüber Forbes, dass das Unternehmen etwa 20 solcher Anfragen pro Jahr erhält – und sie erfüllt, wenn eine gültige gerichtliche Anordnung vorliegt. Das Problem: Windows 11 sichert diese Wiederherstellungsschlüssel standardmäßig in der Microsoft Cloud, sobald ihr euch mit einem Microsoft-Konto anmeldet. Die meisten Nutzer wissen nicht einmal, dass dies passiert.

Das ist kein Einzelfall. Es ist die konkrete Realität des CLOUD Act.

Was ist der CLOUD Act?

Der CLOUD Act (Clarifying Lawful Overseas Use of Data Act) von 2018 ist ein US-Gesetz mit einer einfachen, aber weitreichenden Regelung: US-Behörden können von US-Unternehmen die Herausgabe von Daten verlangen – egal wo auf der Welt die Server stehen.

Die Kernpunkte, die ihr wissen müsst:

1. Der Serverstandort ist irrelevant
Eure Daten können in einem Rechenzentrum in Frankfurt, Amsterdam oder Zürich liegen – wenn das Unternehmen unter US-Kontrolle steht, kann das FBI mit einem Durchsuchungsbefehl darauf zugreifen.

2. Ihr werdet nicht informiert
Die Betroffenen erfahren in der Regel nie, dass ihre Daten abgerufen wurden. US-Behörden können "Gag Orders" (Schweigeanordnungen) verhängen, die es Unternehmen verbieten, ihre Kunden zu informieren.

3. Fast alle großen Tech-Konzerne sind betroffen
Microsoft, Google, Amazon, Apple, Meta (Facebook), Dropbox, Slack, Zoom – sie alle unterliegen dem CLOUD Act, weil sie US-Unternehmen sind.

4. Auch Tochtergesellschaften bieten keinen Schutz
Microsoft Deutschland, Google Switzerland, Amazon Luxembourg – die US-Muttergesellschaft kann angewiesen werden, ihre Tochter zur Datenherausgabe zu zwingen.

Warum das für euch als Privatperson wichtig ist

Viele denken: "Ich habe nichts zu verbergen, warum sollte mich das interessieren?" Hier sind konkrete Gründe:

Eure privaten Fotos, E-Mails und Dokumente
Wenn ihr Microsoft OneDrive, Google Drive oder Dropbox nutzt, liegen eure Familienfotos, persönlichen E-Mails und privaten Dokumente auf US-Servern. US-Behörden können darauf zugreifen – ohne dass ihr es je erfahrt.

Eure Gesundheitsdaten
Nutzt ihr eine Fitness-App eines US-Anbieters? Synchronisiert ihr Gesundheitsdaten in die Cloud? Diese Daten können abgerufen werden.

Eure Kommunikation
WhatsApp (gehört zu Meta/Facebook), Gmail, Outlook.com – alles US-Dienste. Eure Kommunikation kann durchsucht werden.

Geschäftliche Dokumente
Selbstständige und kleine Unternehmen: Vertrauliche Verträge, Kundendaten, Geschäftsgeheimnisse – alles potenziell zugänglich für US-Behörden.

Die Illusion der "EU-Cloud"

Microsoft, Google und Amazon bewerben ihre "EU-Rechenzentren" als sichere Lösung. Das ist Marketing, keine Datenschutzgarantie.

Eure Daten können in Frankfurt auf deutschen Servern liegen – wenn Microsoft Azure sie verwaltet, unterliegen sie trotzdem dem CLOUD Act. Die Gerichtsbarkeit folgt dem Eigentümer, nicht dem Serverstandort.

Selbst wenn ein US-Konzern eine europäische Tochtergesellschaft gründet, die formal die Daten verwaltet: Die US-Muttergesellschaft kann angewiesen werden, die Tochter zur Herausgabe zu zwingen.

Warum Verschlüsselung allein nicht hilft

"Aber meine Daten sind doch verschlüsselt!" höre ich oft. Das Problem: Wer kontrolliert die Schlüssel?

Der BitLocker-Fall zeigt es deutlich: Wenn Microsoft eure Verschlüsselungsschlüssel in der Cloud speichert, kann das Unternehmen gezwungen werden, sie herauszugeben. Eure Verschlüsselung wird wertlos.

Was ihr über Verschlüsselung wissen müsst:

Client-seitige Verschlüsselung: Nur ihr habt die Schlüssel, der Anbieter sieht nur verschlüsselte Daten.
→ Gut: Signal, Tresorit, Proton Drive
→ Schlecht: Standard OneDrive, Google Drive, Dropbox

Server-seitige Verschlüsselung: Der Anbieter verschlüsselt die Daten, hat aber selbst die Schlüssel.
→ Das ist wie ein Tresor, zu dem auch die Bank den Schlüssel hat.

Zero-Knowledge-Architektur: Der Anbieter kann technisch nicht auf eure Daten zugreifen.
→ Genau das fehlt bei Microsoft, Google, Amazon

Apple und Google bieten mittlerweile erweiterten Datenschutz mit Ende-zu-Ende-Verschlüsselung für Cloud-Backups an. Microsoft nicht. Senator Ron Wyden (USA) kritisierte: "Es ist schlicht unverantwortlich, dass Tech-Unternehmen Produkte ausliefern, die es ihnen erlauben, heimlich die Verschlüsselungsschlüssel der Nutzer herauszugeben."

Die praktische Lösung: Open Source und Selbst-Hosting

Die gute Nachricht: Ihr müsst nicht auf Komfort verzichten, um eure Privatsphäre zu schützen. Es gibt ausgereifte, quelloffene Alternativen zu allen gängigen Cloud-Diensten.

1. Linux statt Windows/macOS

Warum Linux?

• Keine Telemetrie, die heimlich Daten sendet
• kein Login oder Anmelde-Zwang
• Keine Cloud-Zwangsintegration
• Volle Kontrolle über euer System
• Keine BitLocker-Schlüssel in fremden Händen

Empfohlene Distributionen für Einsteiger:

• Linux Mint: Perfekt für Windows-Umsteiger
• Ubuntu: Große Community, viel Support
• Fedora: Modern und sicher
• Pop!_OS: Ausgezeichnet für Nvidia-Grafikkarten

Verschlüsselung unter Linux:
LUKS (Linux Unified Key Setup) verschlüsselt eure Festplatte – und ihr verwaltet die Schlüssel. Keine Cloud-Uploads, keine Hintertüren.

2. Nextcloud statt OneDrive/Google Drive

Nextcloud ist die Open-Source-Alternative zu Microsoft 365 und Google Workspace. Alles, was diese Dienste können, kann Nextcloud auch – aber unter eurer Kontrolle.

Features:

• Datei-Synchronisation (wie Dropbox)
• Kalender und Kontakte (CalDAV/CardDAV)
• Office-Dokumente (Collabora Online, ONLYOFFICE)
• E-Mail-Integration
• Videokonferenzen (Nextcloud Talk)
• Aufgabenverwaltung
• Passwort-Manager
• Notizen
• Fotogalerien mit automatischem Upload vom Smartphone

Drei Möglichkeiten, Nextcloud zu nutzen:

Option A: Gemietetes Hosting in Europa
Wir bieten managed, aber auch fertige Nextcloud-Instanzen:

• Einfach, wartungsfrei
• DSGVO-konform
• Rechenzentren in Deutschland, Spanien, Frankreich oder je nach Standort von IONIS
• Ab ca. 16CHF pro Monat

Option B: Eigener Server zuhause (Self-Hosting)
Eine Synology oder UGREEN NAS bei euch im Büro/Zuhause:

• Einmalige Hardware-Kosten (ab ca. 400-800CHF)
• Keine monatlichen Gebühren
• Physische Kontrolle über die Hardware
• Synology DiskStation bietet diverse Apps für Fotos, Datensicherungen und Spiegelungen
• UGREEN NASync läuft perfekt mit Docker/Nextcloud

Option C: Selber Virtual Private Server (VPS) mieten
Ein gemieteter Server bei einem europäischen Hoster:

• Volle Kontrolle
• Root-Zugriff
• Selbst installieren und konfigurieren
• Anbieter: Hetzner, netcup, Contabo, IONOS (alle Deutschland)
• Ab ca. 5€/Monat

3. Freie Protokolle: CalDAV, CardDAV, WebDAV

Einer der größten Vorteile von Open Source: Keine Vendor-Lock-ins durch proprietäre Protokolle.

CalDAV (Kalender): Synchronisiert eure Termine zwischen allen Geräten
CardDAV (Kontakte): Synchronisiert Adressbücher
WebDAV (Dateien): Standard-Protokoll für Datei-Synchronisation

Diese Protokolle funktionieren mit jeder kompatiblen Software:

• Thunderbird (Desktop)
• Evolution (Linux)
• Apple Kalender & Kontakte (iOS/macOS)
• DAVx⁵ (Android)
• Viele weitere

Ihr seid nicht an einen Anbieter gebunden. Wechsel sind einfach – kopiert einfach eure Daten auf einen neuen Server.

Praktische Artikel zum Thema DAV:

https://yourdevice.ch/nextcloud-direkt-via-webdav-in-linux-und-windows-einbinden/

https://yourdevice.ch/thunderbird-kalender-mit-nextcloud-caldav-verbinden/

https://yourdevice.ch/iphone-kalender-auf-android-oder-in-die-nextcloud-uebertragen/

https://yourdevice.ch/kontakte-und-sms-auf-ein-custom-rom-uebertragenkontakte-und-sms-von-android-oder-iphone-auf-custom-rom-uebertragen/

https://yourdevice.ch/kontakte-synchronisieren-mit-nextcloud-android-und-thunderbird/

https://yourdevice.ch/nextcloud-direkt-in-android-einbinden/

https://yourdevice.ch/nextcloud-kalender-mit-android-synchronisieren/

4. E-Mail: Europäische Provider

Statt Gmail/Outlook.com:

• Mailbox.org (Deutschland) – DSGVO-konform, grüner Strom
• Proton Mail (Schweiz) – Ende-zu-Ende-verschlüsselt
• Tutanota (Deutschland) – Zero-Knowledge-Verschlüsselung
• Posteo (Deutschland) – Datenschutz-fokussiert

Ausführlicher Artikel zum Thema:

Alle bieten:

• IMAP/SMTP (Standard-Protokolle)
• CalDAV/CardDAV
• Verschlüsselung
• Keine Werbung
• Kosten: 1-5€ pro Monat

5. Weitere Alternativen

Statt Google Docs:

• Collabora Online (mit Nextcloud)
• ONLYOFFICE (mit Nextcloud)
• LibreOffice (Desktop)

Statt Dropbox:

• Nextcloud (siehe oben)
• Synology Cloud Station
• Seafile

Statt Zoom/Teams:

• Jitsi Meet (Open Source, selbst-hostbar)
• BigBlueButton (ideal für Bildung)
• Nextcloud Talk

Statt Google Analytics:

• Matomo (selbst-hostbar)
• Plausible (Privacy-first, EU-hosted)
• Fathom Analytics

Statt 1Password/LastPass:

• Bitwarden (Open Source, selbst-hostbar)
• KeePassXC (lokal, keine Cloud)
• Vaultwarden (Bitwarden-kompatibler Server)

Schritt-für-Schritt: So steigt ihr aus

Woche 1: Bestandsaufnahme

• Welche Cloud-Dienste nutzt ihr?
• Wo liegen eure wichtigsten Daten?
• Welche Apps synchronisieren in US-Clouds?

Woche 2: Nextcloud einrichten

• Entweder bei einem EU-Hoster anmelden
• Oder eigene NAS/Server aufsetzen
• Nextcloud-Apps auf Smartphone installieren

Woche 3: Daten migrieren

• Fotos aus Google Photos/OneDrive herunterladen
• Dokumente nach Nextcloud verschieben
• Kalender/Kontakte exportieren und importieren

Woche 4: Umstellung abschließen

• E-Mail-Account bei europäischem Provider
• Cloud-Syncs der alten Anbieter deaktivieren
• Alte Accounts kündigen

Was ist mit Unternehmen

Für Firmen gelten besondere Anforderungen, aber die Lösungen sind ähnlich:

• Nextcloud auf einem eigenen Server oder bei EU-Hoster
• Synology mit mehreren DiskBays für Datensicherungen im RAID1 oder 5 oder QNAP/Ugreen NAS im Büro
• Linux-Workstations (Ubuntu/Fedora)
• evt dedizierter Mailserver mit Mailcow, oder Mailhoster bei einem Schweizer Unternehmen wie Informaniak

Rechtliche Absicherung:

• Transfer Impact Assessments durchführen
• Auftragsverarbeitungsverträge (AVV) mit EU-Providern
• Dokumentation der Datenflüsse
• Im Zweifelsfall: Datenschutzbeauftragten konsultieren

Häufige Einwände – und warum sie nicht stimmen

"Ich habe nichts zu verbergen"
→ Würdet ihr euer Tagebuch, eure Bankdaten und eure Fotos einem Fremden auf der Straße geben? Privatsphäre ist ein Grundrecht, kein Privileg für "Verdächtige".

"Das ist mir zu kompliziert"
→ Nextcloud ist genauso einfach wie Dropbox. Drag & Drop, fertig. In den meissten Fällen gibt es die Nextcloud bereits fertig eingerichtet. Wer selber installieren will, nutzt AIO-Docker Setups

"Ich brauche Microsoft Office für die Arbeit"
→ LibreOffice und ONLYOFFICE sind mit allen Office-Formaten kompatibel. Für die meisten Nutzer gibt es keinen funktionalen Unterschied.

"Aber alle anderen nutzen WhatsApp/Gmail"
→ Das ist keine technische, sondern eine soziale Frage. Je mehr Leute wechseln, desto normaler wird es. Seid Vorbild. Nutzt andere Messenger, zeigt den Leuten wie einfach es ist, Signal, oder Element zu verwenden.

"Das ist teurer als die kostenlosen Google-Dienste"
→ Kostenlos bedeutet: Ihr seid das Produkt. Eure Daten werden analysiert, für Werbung genutzt und – wie wir wissen – an Behörden weitergegeben. 10CHF/Monat für echte Privatsphäre sind ein Schnäppchen.

"Was ist, wenn meine NAS kaputt geht?"
→ Backups! Synology bietet Cloud-Backup zu anderen Synology-NAS, oder ihr nutzt einen EU-Backup-Dienst z.B bei Hetnzer's Storage Box. Redundanz ist bei jeder Lösung wichtig – auch Google Drive kann ausfallen.

Fazit: Digitale Souveränität ist möglich

Der CLOUD Act zeigt: Solange US-Unternehmen eure Daten kontrollieren, habt ihr keine Kontrolle. Nicht über die Sicherheit, nicht über den Zugriff, nicht über eure Privatsphäre.

Die Lösung ist nicht kompliziert:

1. Linux statt Windows – volle Systemkontrolle
2. Nextcloud statt OneDrive/Google Drive – eure Cloud, eure Regeln
3. Eigene Hardware (NAS) oder Hosting in der Schweiz oder in der EU bei nicht amerikanischen Unternehmen – physische oder rechtliche Kontrolle
4. Offene Protokolle (CalDAV, WebDAV) – keine Abhängigkeit von einzelnen Anbietern
5. Europäische E-Mail-Provider – DSGVO-konform, keine US-Zugriffe

Der Fall Microsoft/BitLocker/FBI ist nur das jüngste Beispiel. Es wird nicht das letzte sein. Solange ihr US-Dienste nutzt, gebt ihr die Kontrolle ab – freiwillig oder nicht.

Die Technologie für echte digitale Souveränität existiert bereits. Ihr müsst sie nur nutzen.

Jeder Server, den ihr selbst betreibt, jede Nextcloud-Instanz in einem schweizer oder europäischen Rechenzentrum, jeder Wechsel zu Open Source ist ein Schritt weg von Überwachung und hin zu echter Privatsphäre.

Fangt heute an. Eure Daten gehören euch – nicht Microsoft, nicht Google, und schon gar nicht dem FBI.

Quellen und weiterführende Links

1. BitLocker/FBI-Fall:
   • TechRepublic: "Microsoft Shared BitLocker Keys With FBI, Raising Privacy Fears"
     https://www.techrepublic.com/article/news-microsoft-bitlocker-keys-fbi-privacy/
   • Aardwolf Security: "Microsoft Hands Over BitLocker Encryption Keys to FBI"
     https://aardwolfsecurity.com/microsoft-hands-over-bitlocker-encryption-keys-to-fbi/
   • Medium (Mike Broadly): "Microsoft Gave BitLocker Encryption Keys to the FBI"
     https://medium.com/illumination/microsoft-gave-bitlocker-encryption-keys-to-the-fbi-and-most-windows-users-may-not-know-this-0f4c4e911929
2. CLOUD Act Grundlagen:
   • European Data Protection Board (EDPB): "Initial legal assessment of the impact of the US CLOUD Act"
     https://www.edpb.europa.eu/sites/default/files/files/file2/edpb_edps_joint_response_us_cloudact_annex.pdf
   • U.S. Department of Justice: "The Purpose and Impact of the CLOUD Act" (White Paper, 2019)
     https://www.justice.gov/opa/press-release/file/1153446/download
   • Wire: "CLOUD Act - What It Means for EU Data Sovereignty"
     https://wire.com/en/blog/cloud-act-eu-data-sovereignty
   • LexisNexis: "Cloud Act and GDPR: What implications for EU companies' data protection?"
     https://www.lexisnexis.com/blogs/int-legal/b/insights/posts/cloud-act-gdpr-implications
   • Exoscale: "CLOUD Act vs. GDPR: The Conflict About Data Access Explained"
     https://www.exoscale.com/blog/cloudact-vs-gdpr/
3. Schrems-Urteile:
   • Court of Justice of the European Union: "Schrems II" (Case C-311/18), 16. Juli 2020
     https://curia.europa.eu/juris/liste.jsf?num=C-311/18
   • The New Stack: "What GDPR, Schrems 2 and the End of Privacy Shield Means"
     https://thenewstack.io/what-gdpr-schrems-2-and-the-end-of-privacy-shield-means-to-your-kubernetes-based-service/
   • Anexia: "Implications of the Schrems II Judgement on Cloud Provider"
     https://anexia.com/blog/en/schrems-ii-cloud-provider/
4. Trans-Atlantic Data Privacy Framework:
   • European Commission: Implementing Decision (EU) 2023/1795
     https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj
   • IAPP: "How could Trump administration actions affect the EU-U.S. Data Privacy Framework?"
     https://iapp.org/news/a/how-could-trump-administration-actions-affect-the-eu-u-s-data-privacy-framework-
   • Taylor Wessing: "Die Zukunft des EU-U.S. Data Privacy Frameworks"
     https://www.taylorwessing.com/de/insights-and-events/insights/2025/01/eu-us-data-privacy-frameworks
   • Lewis Silkin: "Could Trump play the Trump card against the Data Protection Framework?"
     https://www.lewissilkin.com/insights/2025/03/30/could-trump-play-the-trump-card-against-the-data-protection-framework-102k26v
   • mailbox.org: "CLOUD Act: European companies must act now"
     https://mailbox.org/en/post/digital-sovereignty-in-uncertain-times
   • KPMG: "Data Privacy Framework: Datenaustausch mit den USA erneut auf dem Prüfstand"
     https://klardenker.kpmg.de/financialservices-hub/data-privacy-framework-datenaustausch-mit-den-usa-erneut-auf-dem-pruefstand/
   • American Security Project: "Tech Tensions—The Future of the U.S.-EU Data Privacy Framework"
     https://www.americansecurityproject.org/transatlantic-tech-tensions-the-future-of-the-u-s-eu-data-privacy-framework/
5. Praktische Anleitungen:
   • Nextcloud Homepage: https://nextcloud.com
   • LibreOffice: https://www.libreoffice.org
   • Linux Mint: https://linuxmint.com
   • Ubuntu: https://ubuntu.com
   • Fedora: https://fedoraproject.org
   • Pop!_OS: https://pop.system76.com
   • Mailbox.org: https://mailbox.org
   • Proton: https://proton.me
   • Tutanota: https://tutanota.com
   • Bitwarden: https://bitwarden.com
   • Jitsi Meet: https://meet.jit.si
   • Matomo: https://matomo.org
6. Europäische Hoster:
   • Hetzner (Deutschland): https://www.hetzner.com
   • netcup (Deutschland): https://www.netcup.de
   • Contabo (Deutschland): https://contabo.com
   • Infomaniak (Schweiz): https://www.infomaniak.com
   • OVHcloud (Frankreich): https://www.ovhcloud.com
   • Scaleway (Frankreich): https://www.scaleway.com

The post Der CLOUD Act: Eure Daten und die amerikanische Software appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Fall: FBI erhält Vollzugriff auf verschlüsselte Laptops

Im US-Außengebiet Guam ermittelten Bundesrichter gegen Verdächtige, die sich angeblich am Covid-Hilfsprogramm bereichert hatten. Die Beweise sollten drei Laptops liefern – verschlüsselt mit BitLocker. Statt an der Verschlüsselung zu scheitern, forderten die Ermittler per Gerichtsbeschluss die Schlüssel direkt von Microsoft an. Der Konzern lieferte bereitwillig. Pro Jahr soll es etwa 20 solcher Fälle geben – Tendenz vermutlich steigend.

Was hier so technisch klingt, ist ein fundamentaler Bruch des Verschlüsselungsversprechens: Festplattenverschlüsselung soll eure Daten vor unbefugtem Zugriff schützen. Wenn aber der Hersteller der Verschlüsselungssoftware selbst Zugang zu euren Schlüsseln hat und diese auf Anfrage herausgibt, dann ist die Verschlüsselung wertlos.

Das eigentliche Problem: Microsoft speichert eure Schlüssel standardmäßig in der Cloud

Das Kernproblem liegt in Microsofts Systemarchitektur. Bei der Installation von Windows 10 und 11 werdet ihr standardmäßig aufgefordert, euch mit einem Microsoft-Konto anzumelden. Was Microsoft euch dabei verschweigt: Euer BitLocker-Wiederherstellungsschlüssel landet automatisch und ungefragt in der Microsoft-Cloud. Unverschlüsselt. Für Microsoft – und damit für US-Behörden – jederzeit zugänglich.

Diese „Komfort-Funktion" ist standardmäßig aktiviert. Die meisten Nutzer haben keine Ahnung, dass ihre vermeintlich sichere Festplattenverschlüsselung durch diese Hintertür komplett ausgehebelt wird. Microsoft begründet dies mit der Benutzerfreundlichkeit: Wer seinen Schlüssel verliert, kann so einfacher auf seine Daten zugreifen. Die Wahrheit ist: Ihr verliert die Kontrolle über eure eigenen Daten.

Microsoft selbst räumt das Risiko in einer Stellungnahme ein: „Wenn die Wiederherstellung von Schlüsseln einfach ist, besteht auch das Risiko eines ungewollten Zugangs." Trotzdem bleibt die Cloud-Speicherung der Schlüssel der Standard. Die Verantwortung wird heuchlerisch auf euch abgewälzt: „Kunden sind in der besten Position, um zu entscheiden, wie sie ihre Schlüssel verwalten" – nur dass die meisten Kunden nicht einmal wissen, dass diese Entscheidung getroffen wird.

Massenüberwachung durch Design: Microsoft ermöglicht Behördenzugriff auf Millionen Geräte

Die Dimension dieses Problems wird deutlich, wenn man sich die Verbreitung von Windows ansieht. Hunderte Millionen Geräte weltweit nutzen BitLocker mit aktivierter Cloud-Schlüssel-Speicherung. Das bedeutet: Microsoft und damit potentiell auch US-Behörden haben theoretisch Zugang zu den Festplatten von Millionen Menschen – Privatpersonen, Unternehmen, Behörden, Journalisten, Aktivisten.

Kryptographie-Experte Matt Green von der Johns Hopkins University bringt es auf den Punkt: „Das sind private Daten auf privaten Computern und Microsoft hat die architektonische Entscheidung getroffen, einen Zugang zu diesen Daten zu haben." Green hebt hervor, dass Microsoft damit alleine steht: Apple und Google implementieren ihre Verschlüsselungssysteme ohne zentrale Zugangsmöglichkeiten.

Das FBI-Beispiel zeigt: Wenn Behörden die Möglichkeit haben, nutzen sie diese auch. Besonders problematisch: Mit den BitLocker-Schlüsseln erhalten Ermittler Zugriff auf das komplette Gerät – nicht nur auf die Daten, die für den jeweiligen Fall relevant sind. Ein digitaler Generalschlüssel für euer gesamtes digitales Leben.

NSAKEY: Microsoft und die NSA – eine lange Geschichte der Zusammenarbeit

Die aktuelle BitLocker-Kontroverse ist kein Einzelfall, sondern reiht sich in eine lange Geschichte fragwürdiger Kooperationen zwischen Microsoft und US-Geheimdiensten ein. 1999 entdeckte der Kryptographie-Experte Andrew D. Fernandes eine Variable namens „_NSAKEY" in Windows NT 4.0 – einen 1024-Bit öffentlichen Schlüssel mit direktem Bezug zur National Security Agency (NSA).

Die Entdeckung löste massive Spekulationen aus: Hatte die NSA eine Hintertür in Windows eingebaut? Microsoft dementierte vehement und behauptete, der Name stamme lediglich daher, dass die NSA die technische Prüfbehörde für US-Kryptographie-Exportkontrollen sei. Die Erklärung überzeugte Sicherheitsexperten nicht. Besonders brisant: In Windows 2000 wurde ein dritter, nicht dokumentierter Schlüssel gefunden, der laut Sicherheitsforscher Dr. Nicko van Someren „fishy" aussah.

Die Parallelen zum aktuellen BitLocker-Skandal sind offensichtlich: Damals wie heute geht es um kryptographische Schlüssel in Windows-Systemen, damals wie heute gibt es Verbindungen zu US-Geheimdiensten, und damals wie heute versucht Microsoft, die Vorwürfe herunterzuspielen.

https://en.wikipedia.org/wiki/NSAKEY

Senator Wyden: „Unverantwortlich, Produkte auszuliefern, die heimliches Ausliefern von Nutzerdaten ermöglichen"

Die politische Kritik ist eindeutig. Ron Wyden, demokratischer Senator und bekannter Datenschutzaktivist, verurteilt Microsofts Vorgehen scharf: Für Tech-Konzerne sei es unverantwortlich, Produkte auszuliefern, die das heimliche Ausliefern von Nutzerdaten ermöglichen.

Auch Windows Central bezeichnet es als „schockierend", dass Microsoft die BitLocker-Schlüssel ungesichert in Nutzerkonten hinterlegt. Nutzer würden bei der Installation aktiv dazu hingeleitet, das Schlüssel-Backup zu aktivieren – ohne über die massiven Risiken für ihre Privatsphäre aufgeklärt zu werden. Das ist keine Fahrlässigkeit, das ist System.

Apple und Google: Kein Grund zum Jubeln – auch sie kooperieren mit Behörden

Die Tech-Industrie präsentiert sich gerne als Verteidiger eurer Privatsphäre. Die Realität sieht anders aus. Zwar lieferte sich Apple 2016 einen medienwirksamen Rechtsstreit mit dem FBI um das iPhone des San Bernardino-Attentäters – doch hinter den Kulissen ist die Geschichte wesentlich schmutziger.

Was die meisten nicht wissen: Apple händigt seit Jahren bereitwillig iCloud-Backup-Daten an US-Behörden aus. Laut eigenen Transparenzberichten übergab Apple allein in der ersten Hälfte eines Jahres in 1.568 Fällen Nutzerdaten an die Regierung. Der Grund: iCloud-Backups waren bis 2022 nicht Ende-zu-Ende verschlüsselt – Apple hatte die Schlüssel und konnte auf richterliche Anordnung zugreifen.

Noch brisanter: 2018 plante Apple, iCloud-Backups endlich vollständig Ende-zu-Ende zu verschlüsseln. Nach Gesprächen mit dem FBI ließ Apple das Projekt fallen. Reuters berichtete, dass Apple "überzeugt" wurde von den Argumenten der Behörden. Die angebliche Datenschutz-Ikone knickte ein, um es sich nicht mit dem FBI zu verscherzen.

Erst Ende 2022 – vier Jahre später – führte Apple "Advanced Data Protection" ein, mit echter Ende-zu-Ende-Verschlüsselung für iCloud. Der Haken: Es ist ein Opt-In Feature. Standardmäßig landen eure iCloud-Backups weiterhin unverschlüsselt auf Apples Servern, zugänglich für Behörden mit Gerichtsbeschluss.

Google steht nicht besser da. Der Konzern baute 2009 eine Backdoor in Gmail, um Behörden bei gültigen Gerichtsbeschlüssen Zugriff zu gewähren. Diese Backdoor wurde von chinesischen Hackern ausgenutzt, um auf sensible US-Überwachungsziele zuzugreifen – ein perfektes Beispiel dafür, warum Hintertüren niemals sicher sind. Sicherheitsexperte Bruce Schneier bestätigte: "Die chinesischen Hacker nutzten genau die Backdoor, die für US-Behörden geschaffen wurde."

Gmail-Emails werden unbegrenzt gespeichert und bei Bedarf an Behörden herausgegeben. Googles automatische Email-Auswertung für Werbezwecke ist dabei nur die Spitze des Eisbergs. Google nutzt eure Daten auch in eigenen Rechtsstreitigkeiten: Im Waymo-vs-Uber-Fall präsentierte Google die Suchverläufe eigener Ex-Mitarbeiter vor Gericht – Suchanfragen wie "wie lösche ich Google Drive Dateien permanent von meinem Computer" wurden gegen sie verwendet.

Die bittere Wahrheit: Alle großen US-Tech-Konzerne kooperieren mit Behörden, wenn es darauf ankommt. Der Unterschied zu Microsoft ist graduell, nicht prinzipiell. Während Microsoft eure BitLocker-Schlüssel standardmäßig in der Cloud speichert, tut Apple dasselbe mit iCloud-Backups (außer ihr aktiviert manuell Advanced Data Protection). Während Microsoft auf richterliche Anordnung Schlüssel herausgibt, tut Apple dasselbe mit Backup-Daten.

Microsoft ist nicht die einzige Gefahr – es ist nur die offensichtlichste. Wer seine Daten wirklich schützen will, darf sich nicht auf das Marketing von Tech-Konzernen verlassen, egal ob Microsoft, Apple oder Google. Die einzige verlässliche Lösung ist echte, lokale Verschlüsselung ohne Cloud-Speicherung – wie sie LUKS unter Linux bietet.

Microsoft behauptet seit 2013, Hintertüren abgelehnt zu haben – die Realität sieht anders aus

Microsoft betont öffentlich, dass US-Sicherheitsbehörden bereits 2013 den Einbau einer Hintertür in BitLocker gefordert hätten und man sich dem verweigert habe. Diese Aussage klingt nach Widerstand gegen staatliche Überwachung – ist aber blanker Hohn angesichts der Tatsachen.

Wozu eine zusätzliche Hintertür einbauen, wenn die vorhandene Architektur bereits vollständigen Zugriff ermöglicht? Indem Microsoft eure BitLocker-Schlüssel standardmäßig in seiner Cloud speichert, hat der Konzern faktisch eine Hintertür geschaffen – nur dass diese nicht als solche bezeichnet werden muss. Die öffentliche Verweigerungshaltung ist PR, die Praxis ist Massenüberwachungsinfrastruktur.

LUKS unter Linux: So geht echte Verschlüsselung

Die gute Nachricht: Es gibt Alternativen. Unter Linux-Systemen kommt standardmäßig LUKS (Linux Unified Key Setup) zum Einsatz – ein Open-Source-Verschlüsselungssystem, das echte Sicherheit bietet.

Der fundamentale Unterschied: Bei LUKS bleiben alle Schlüssel ausschließlich auf eurem eigenen System. Es gibt keine Cloud-Speicherung, keine automatische Übertragung, keine zentrale Stelle, die Zugriff hat. Euer Schlüssel existiert nur auf eurer Hardware – und damit habt ihr die vollständige Kontrolle.

LUKS basiert auf dem dm-crypt-Kernel-Modul und setzt auf bewährte Verschlüsselungsalgorithmen wie AES. Der gesamte Code ist Open Source, kann von Sicherheitsforschern weltweit überprüft werden und wird von der Community kontinuierlich auf Schwachstellen untersucht. Das Gegenteil von Microsofts geschlossener, intransparenter BitLocker-Implementierung.

Die Einrichtung von LUKS erfolgt bei den meisten Linux-Distributionen (Ubuntu, Fedora, Debian, etc.) bereits während der Installation. Ihr wählt ein starkes Passwort – fertig. Kein Microsoft-Konto, keine Cloud, keine Hintertüren. Die Verschlüsselung ist standardmäßig so stark, dass selbst Geheimdienste mit massiver Rechenleistung eure Daten nicht entschlüsseln können – vorausgesetzt, ihr nutzt ein sicheres Passwort.

LUKS unterstützt außerdem Multiple-Key-Slots: Ihr könnt mehrere Passwörter oder Schlüsseldateien für denselben verschlüsselten Container einrichten, etwa für verschiedene Teammitglieder. Ihr könnt Schlüssel jederzeit hinzufügen oder entfernen, ohne die gesamte Partition neu verschlüsseln zu müssen. Echte Kontrolle, echte Flexibilität. Es können auch nachträglich Ordner mit LUKS verschlüsselt werden.

Wie überprüft ihr, ob euer BitLocker-Schlüssel in der Microsoft-Cloud liegt

Falls ihr Windows nutzt, solltet ihr sofort überprüfen, ob Microsoft euren BitLocker-Schlüssel gespeichert hat:

1. Meldet euch bei eurem Microsoft-Konto an (account.microsoft.com)
2. Navigiert zu „Geräte" und dann zu „BitLocker-Wiederherstellungsschlüssel"
3. Wenn dort Schlüssel aufgelistet sind, hat Microsoft Vollzugriff auf eure verschlüsselten Festplatten

Die Funktion lässt sich deaktivieren – allerdings müsst ihr eure BitLocker-Schlüssel dann selbst sicher verwahren. Verliert ihr sie, sind eure Daten unwiederbringlich verloren. Das ist der Preis echter Sicherheit: Eigenverantwortung statt bequemer Überwachung. Leider ist es jedoch fraglich, ob die Keys dann auch wirklich von den Servern gelöscht sind, die Antwort darauf, kann sich jeder selber geben..

Die bessere Lösung: Steigt auf Linux mit LUKS um. Open Source, transparent, sicher.

Trump 2.0: Die nächste Runde im Crypto-Krieg

Mit Donald Trumps Rückkehr ins Weiße Haus im Januar 2025 dürfte das Thema Verschlüsselung und Behördenzugriff wieder auf die politische Agenda rücken. Trump attackierte bereits in seiner ersten Amtszeit Tech-Konzerne wegen ihrer Verschlüsselungssysteme – insbesondere Apple.

Die entscheidende Frage: Wird Microsoft unter einer Trump-Administration noch stärker unter Druck geraten, den Behördenzugriff auszuweiten? Oder wird Microsoft – wie in der Vergangenheit – bereitwillig kooperieren, während sich andere Konzerne wehren?

Für euch als Nutzer bedeutet das: Die Bedrohung für eure Privatsphäre durch staatliche Überwachung wird nicht abnehmen. Im Gegenteil. Umso wichtiger ist es, jetzt auf echte Verschlüsselung zu setzen – auf Systeme, die technisch keine Hintertüren ermöglichen.

Soll ich Bitlocker deaktivieren

Nein, Bitlocker ist ein Schutz gegen Datendiebstahl durch physischen Zugriff auf eure Hardware. Solltet ihr den Laptop verlieren, oder wird dieser gestohlen, ist Bitlocker ein effektiver Schutz gegen Zugriff auf die Daten durch unbefugte Dritte. Jemand der die Festplatte ausbaut, hat somit keinen Zugriff auf die Daten auf der verschlüsselten Festplatte. Ohne Bitlocker kann jeder, der die Platte ausbaut, eure Daten kinderleicht auslesen.

Fazit: Microsofts BitLocker ist Sicherheitstheater, kein Schutz

BitLocker mit aktivierter Cloud-Speicherung ist keine Verschlüsselung im eigentlichen Sinne – es ist Sicherheitstheater. Es vermittelt euch ein falsches Gefühl von Sicherheit, während eure Daten für Microsoft und US-Behörden jederzeit zugänglich bleiben.

Die Geschichte von NSAKEY bis zur aktuellen FBI-Affäre zeigt: Microsoft hat eine lange Tradition der Kooperation mit Geheimdiensten. Der Konzern trifft bewusst Architekturentscheidungen, die Massenüberwachung ermöglichen, und schiebt die Verantwortung heuchlerisch auf euch als Nutzer ab.

Echte Sicherheit gibt es nur mit echter Verschlüsselung. LUKS unter Linux bietet genau das: Open Source, transparent, ohne Hintertüren. Eure Schlüssel bleiben auf eurem System, unter eurer Kontrolle. Kein Konzern, keine Behörde, niemand hat Zugriff – außer ihr selbst.

Weiterführende Links:

• LUKS-Dokumentation: https://gitlab.com/cryptsetup/cryptsetup
• EFF Guide: Surveillance Self-Defense
• Microsofts BitLocker-Schlüssel https://account.microsoft.com/devices überprüfen:

Hinweis: Ihr könnt bei uns in den Kommentaren gerne eure Erfahrungen mit BitLocker oder LUKS teilen. Habt ihr bereits auf Linux umgestellt? Welche Hürden gab es? Lasst es uns wissen!

The post BitLocker-Skandal: Microsoft liefert eure Festplattenschlüssel an das FBI appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Die meisten ASIC Miner laufen nicht optimal ab Werk. Hersteller setzen konservative Standardeinstellungen, um zu garantieren, dass alle Chips - selbst die schwächsten aus der Produktion - stabil laufen. Das bedeutet aber auch: Euer spezifischer Chip könnte deutlich mehr leisten, effizienter arbeiten oder mit weniger Spannung auskommen. Jeder Chip ist anders, und genau hier liegt euer Potenzial!

Was euch in diesem Guide erwartet:

Lernt die Geheimnisse des Core Voltage & Frequency Tuning kennen - die beiden wichtigsten Parameter, die über Performance, Effizienz und Stabilität eurer Mining-Hardware entscheiden. Ob ihr nun:

• Probleme beheben wollt: Niedrige Hashrates, instabile Chips oder Hardware-Errors beseitigen
• Effizienz steigern möchtet: Bis zu 20-30% weniger Stromverbrauch bei minimalem Hashrate-Verlust (Undervolting)
• Maximum Performance anstrebt: Sicher übertakten für 5-15% mehr Hashrate (Overclocking)

Dieser umfassende Guide deckt alle drei Szenarien ab - von der Diagnose über die Optimierung bis hin zum sicheren Pushen eurer Hardware-Grenzen. Mit konkreten Beispielen, Schritt-für-Schritt-Anleitungen und technischem Hintergrundwissen ausgestattet, werdet ihr nach diesem Artikel genau wissen, wie ihr das Maximum aus euren Mining-Geräten herausholt!

Anfänger-Hinweis: Falls ihr neu in der Mining Welt seid, empfehlen wir euch, zunächst die Bitcoin Mining Bibel zu lesen, damit ihr die Grundlagen des Minings kennen lernt.

Quick Explain: Spannung & Frequenz

Core Voltage

Stellt euch dies als die Stromversorgung des Mining-Chips' Gehirn (dem Core) vor. Gemessen in Millivolt (mV), bestimmt es, wie viel elektrische Energie dem Chip für seine Berechnungen zur Verfügung steht.

Zu niedrige Spannung führt zu Instabilität ungültigen Shares ("Invalid Shares" oder "Summit-Fehler") und somit zu schlechterer Leistung; zu hohe Spannung erhöht die Wärmeerzeugung dramatisch und riskiert Beschädigungen.

Technischer Hintergrund: Der Chip führt im Grunde Berechnungen durch, bei denen Transistoren zwischen An- und Ausgängen schalten. Eine niedrigere Spannung führt dazu, dass diese Übergänge nicht schnell genug erfolgen oder fehlschlagen, besonders bei höheren Frequenzen. Die Spannung bestimmt auch den Schwellenwert, den die Transistoren erreichen müssen – unter diesem Punkt funktioniert der Chip nicht mehr zuverlässig.

Taktfrequenz

Gemessen in Megahertz (MHz), ist dies die Geschwindigkeit, mit der der Chip seine Hash-Berechnungen durchführt.

Höhere Frequenz = mehr Berechnungen pro Sekunde = potentiell höhere Hashrate, aber es benötigt auch mehr Stromzufuhr und erzeugt wesentlich mehr Wärme.

Technischer Kontext: Die Frequenz bestimmt, wie viele Male pro Sekunde die internen Logik-Gatter schalten. Bei SHA-256 (Bitcoin Mining) müssen Millionen von logischen Operationen pro Hash durchgeführt werden. Die Frequenz multipliziert sich direkt in der Hashrate-Berechnung.

Die tiefe Verbindung: Voltage × Taktfrequenz

Diese zwei Einstellungen sind nicht unabhängig.

Frequenz erhöhen erfordert Spannung: Wenn ihr die Frequenz erhöht, schalten die Transistoren schneller. Dies erfordert jedoch, dass die Spannung hoch genug ist, um diese schnelleren Übergänge zuverlässig zu treiben. Eine zu niedrige Spannung bei hoher Frequenz führt zu "Timing Violations" – der Chip kann seine Operationen nicht in der geforderten Zeit abschließen.

Spannung erhöhen kostet Energie & Wärme: Eine höhere Spannung bedeutet, dass mehr Strom durch die Transistoren fließt. Dies folgt dem Ohmschen Gesetz: P = V² × I / R. Da die Verlustleistung mit dem Quadrat der Spannung zunimmt (oder mit V × I), steigt die Wärmeerzeugung superlinear – eine kleine Spannungserhöhung kann zu einer großen Temperaturerhöhung führen.

Effizienzkurve (J/TH): Energieeffizienz wird in Joules per Terahash (J/TH) gemessen. Der optimale Punkt für die meisten ASIC-Chips liegt typischerweise im mittleren Spannungsbereich (nicht zu niedrig, nicht zu hoch) und bei einer Frequenz, die nicht zu weit über dem Factory Default liegt. Das "sweetspot" variiert stark je nach Chip und Batch.

Gibt es eine universelle "beste" Einstellung

Die kurze Antwort: Nein.

Die Werkseinstellungen (z.B. 1150mV / 550MHz für einen ASIC Chip wie den BM1370) sind lediglich sichere Startpunkte, die auf Durchschnittswerten über tausende von Chips basieren.

Warum Variationen existieren:

1. Silizium-Loterie (Silicon Binning): Auch Chips aus demselben Produktionslos zeigen geringfügige physikalische Variationen. Der Halbleiterprozess ist nicht perfekt – Dotierungskonzentrationen, Transistorgeometrie und andere Parameter weichen leicht ab. Das bedeutet, dass jeder Chip ein leicht unterschiedliches Optimal-Fenster für Spannung/Frequenz hat.
2. Thermal Interface & Wärmeableitung: Die Qualität der Wärmepaste, die Aufpressdruck und die Anbindung des Heatsinks variieren zwischen Chips. Ein Chip mit besserer thermischer Anbindung kann höhere Frequenzen bei gleicher Temperatur tolerieren.
3. Power Delivery: Die Qualität der Stromversorgung und die Stabilität eurer PSU beeinflussen, welche Spannungen zuverlässig geliefert werden können.
4. Umgebungstemperatur & Kühlung: Ein Miner in einer kalten Umgebung mit ausgezeichnetem Airflow wird anders OC-grenzen haben als einer in einem warmen Serverraum.

Wann ist dieser Leitfaden relevant

Dieser Guide ist für 3 Szenarien sinnvoll:

1. Performance-Optimierung (Overclocking – OC)

Sicher zusätzliche Performance heraus holen – natürlich mit Vorsicht!

2. Undervolting und Effizienz Tuning

Möchtet ihr die maximale Effizienz aus eurem Miner herausholen, dann seid ihr in diesen Abschnitt genau richtig. Wir senken die ASIC Spannung so ab, damit der Stromverbrauch sinkt, und die Effizienz des Geräts steigt. Das gute daran, es ist praktisch nicht gefährlich.

3. Troubleshooting Underperforming Chips

Wenn euer Miner-Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "HW Errors") zeigt, oder die Gesamthashrate konsistent unter Erwartungen liegt – dies deutet oft auf unzureichende Core Voltage für die aktuelle Frequenz hin.

Häufige Fehler:

• Low Hashrate: Der Chip hasht, sendet aber weniger als erwartete Shares
• Invalid Shares: Der Chip produziert ungültige Hashes (falsche Berechnungen)
• Hardware Errors (HW): Der Chip schlägt bei der Verarbeitung fehl

Vorbereitungen

Macht euch mit dem User Interface von AxeOS oder der NerdQ Geräte vertraut. Beide Geräte bieten eine saubere und übersichtliche Oberfläche an, um die Performance der Geräte bestens zu überwachen.

AxeOS:

NerdQ OS:

In den Dashboards habt ihr den Überblick zur Hashrate, dem Stromverbrauch, die Input Voltage des Netztteils, die ASIC Spannung in Volt, die ASIC Temperatur, die VRM/VR Temperatur, die Lüfterdrehzahl und die Lüfterdrehzahl in Prozent. Diese Angaben helfen euch, den aktuellen Stand des Gerätes einzuschätzen.

OC Modus freischalten

In AxeOS müsst ihr Einstellungen/Settings des Gerätes, und dort den OC Modus freischalten. Dazu muss am Ende des Browserlinks ein

?oc=

angehängt werden. Aus

http://192.168.5.30/#/settings

wird

http://192.168.5.30/#/settings?oc=

Danach zeigt sich ein gelber Banner mit einem Warnhinweis:

Auf den NerdQ Geräten könnt ihr das über einen einfach Button tun:

Danach könnt ihr die Frequenzen und die Spannungen freier auswählen und feiner abstimmen

Lüftersteuerung kennen lernen

Bitaxen und NerdQ Geräte verfügen über eine automatische Lüftersteuerung, welche nach einem Temperatur Target arbeitet. Heisst also, die Lüfter Geschwindigkeit passt sich automatisch an die ASIC Temperatur an. Erhöht ihr Frequenz und Spannung, steigt nicht unbedingt die Chip Temperatur, sondern die Lüfterdrehzahl erhöht sich, bis das Maximum von 100% erreicht ist.

Aus Sicherheitsgründen sollte ein Lüfter nicht bei 100% im automatischen Modus laufen, da hier keinerlei Reserven mehr bestehen, vor allem, wenn es im Raum wärmer werden sollte. Ein gutes Temperatur Target liegt bei 60°c. Optimalerweise dreht der Lüfter dabei bei ca 50% seiner maximalen Drehzahl

Die Einstellungen dazu findet ihr in den Settings von NerdQ oder AxeOS:

Bei Geräten mit besseren Kühlern kann man das Temperatur Target auch etwas absenken, sollte sich der Kühler zu fest langweilen, und der Lüfter mit sehr niedriger Drehzahl arbeiten. Generel kann man sagen, dass sich kühlere Chips besser übertakten lassen.

Temperatur Grenzen der Bitaxen und NerdQ Geräten

Wichtig zu wissen: die ASIC Chips sollten wenn möglich 70° nicht überschreiten. Aus Sicherheitsgründen fahren die meissten Home Miner bei über 70° herunter. Danach schaltet sich der Überhitzungsschutz ein. Dieser wird euch deutlich in den Einstellungen der Miner angezeigt. Deaktiviert den Überhitzungsschutz, und stellt die Standardwerte der Chips wieder ein (BM1370 = 525mhz bei 1.15v)

Teil 1: Der vorsichtige Weg zum Overclocking

⚠️ WARNUNG: Overclocking birgt Risiken

Bevor ihr weiterlest, müsst ihr diese Risiken verstehen und akzeptieren:

1. Fortgeschrittenes Wissen erforderlich

• Ihr benötigt ein solides Verständnis von Elektronik, eurer spezifischen Hardware und Kühlungsgrenzen
• Ein naives "einfach mehr Frequenz" Experiment wird mit hoher Wahrscheinlichkeit zu Problem und Instabilitäten führen

2. Hardware-Schadensrisiko

• Bleibende Schäden möglich: Falsche Einstellungen können euren ASIC-Chips oder Hashboards permanent beschädigen
• Point of No Return: Einige Schäden (z.B. gebrannte Transistoren) können nicht repariert werden
• Kettenschaden-Effekt: Ein überhitzter Chip kann umliegende Komponenten beschädigen

3. Wärme & Effizienz Herausforderungen

• Overclocking kann die Wärmeerzeugung dramatisch erhöhen – potentiell um 50% oder mehr
• Power Consumption erhöht sich (gemessen in Watts): Dies ist nicht linear. Eine 10% Frequenzerhöhung + Spannungserhöhung könnte zu 20–30% mehr Stromverbrauch führen
• Effizienz sinkt (gemessen in J/TH – Joules pro Terahash): Wenn ihr 40% mehr Strom für 15% mehr Hashrate braucht, wurde eure Effizienz durch OC unverhältnismässig verschlechtert
• Lebensdauer der Hardware kann drastisch sinken (halbe Lebensdauer ist nicht selten bei aggressivem OC)

4. Kühlung ist existentiell

• Ihr solltet eine ausreichende Kühlung haben, bevor ihr OC versucht:
  • Niedrige Umgebungstemperaturen (idealerweise < 25°C)
  • optimierter Airflow, guter Lüfter
  • Hochwertige Heatsinks oder sogar Flüssigkeitskühlung für extreme OC
• Überhitzung ist der schnellste Weg zum Versagen. Ein überheizter Chip wird zum "Brick".

5. Garantieverlust

Overclocking führt zum Garantieverlust eures Gerätes. Wenn er durchbrennt, wars das. Es gibt sicherlich keinen Ersatz vom Verkäufer!

Wenn ihr die Risiken akzeptiert: Die methodische OC-Prozedur

Voraussetzungen

Bevor ihr ein einziges MHz erhöht, überprüft diese Bedingungen:

1. Baseline Stabilität

• Euer Miner läuft 100% stabil mit den aktuellen Einstellungen
• Keine unerklärten Fehler oder spontanen Reboots über Stunden hinweg
• Alle Chips senden konsistent gültige Shares und die erwartete Hashrate wird auch tatsächlich erreicht

2. Temperatur im grünen Bereich

• ASIC Core Temp liegt stabil bei ~60°C oder eurem eingestelltem Target
• VRM (Voltage Regulator) liegt unter ~70°C
• Der Lüfter dreht bei 50% seiner maximalen Drehzahl im automatischen Modus
• Diese "Sicherheitsmargen" geben euch Platz für die Wärmesteigerung durch OC

3. Stromversorgung mit Headroom

• Euer Netzteil hat 30% Kopfraum über dem aktuellen Stromverbrauch
  • Beispiel: Wenn euer Miner aktuell 75W zieht, sollte euer Netzteil mind. 110W haben
  • Grund: Netzteile die am Limit arbeiten PSUs werden instabil, liefern niedrigere Spannung, können ausfallen
• Überprüft die PSU-Kabelqualität (keine beschädigten, frayed oder überheizten Kabel)

Eine Bitaxe mit aussreichender Kühlung und genügend Spielraum:

Die Temperatur liegt bei 60°, der Lüfter ist erst bei 42%

Overclocking Schritt für Schritt durchführen

Schritt 1: Kleine Frequenzerhöhung

Erhöht die Frequenz für der Chips um +10 MHz (z.B. von 550 auf 560MHz).

Warum +10 MHz?

• Groß genug, um messbar zu sein (nicht in dem Rauschen der Mess-Variabilität)
• Klein genug, um bei Instabilität schnell zu erkennen
• Standard in der Mining-Community

Schritt 2: Speichern & Neustart

In neueren Version von AxeOS und NerdQ OS muss das Gerät nicht neugestartet werden.

Schritt 3: Kritisches Monitoring (15–30+ Minuten)

Das ist der wichtigste Schritt. Geht ins Dashboard und beobachtet intensiv:

3a) Stabilität & Submissions

• Sind alle Shares gültig? Keine neuen "Invalid Shares" oder "HW Errors"?
• Ist die beobachtete Hashrate nahe der erwarteten Hashrate für die neue Frequenz?
  • Die Firmware des Miners oder der Pool sollte euch die erwartete Rate für 560MHz anzeigen
  • Wenn eure beobachtete Hashrate sinkt oder unter der Erwartung liegt, ist das ein Zeichen, dass zu wenig Spannung am Chip anliegt
• Konsistenz: Ist die Hashrate stabil oder "flattert" sie?

3b) Temperatur-Überwachung

• Temperatur-Steigerung: Wieviel ist die Drehzahl des Lüfters, oder die Temperatur des ASICS und der VRMs durch die +10MHz Frequenzerhöhung gestiegen?

3c) Hardware Errors & Log-Überwachung

• Tauchen neue Fehler auf? Spezifisch:
  • nonce_range_err – kann auf Timing Violations hindeuten
  • device_hw_errors – Chip-Fehler
  • shares_stale – seltener, aber kann auf "zu lange Berechnung" hinweisen

Wo beobachten:

• Miner Web-Interface (Live Hashrate, Temperature, Error Counter)
• Pool Dashboard: Ist die Accepted vs. Rejected Rate stabil?

Das Dashboard zeigt eine stabile Temperatur, der Lüfter ist nicht ausgereizt, die VRMs bleiben schön kühl.

Schritt 4: Stabil? Wiederholt die Frequenzerhöhung

Falls alles ok ist nach 30 Minuten Monitoring:

1. Erhöht die Frequenz um weitere +10 MHz (z.B. 560 → 570MHz)
2. Speichert oder Startet neu bei älteren Versionen
3. Geht zurück zu Schritt 3 – monitort erneut

Typisches OC-Szenario:

550MHz (Baseline, stabil) 
→ 560MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 570MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 580MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 590MHz (+10) - stabil, +1°C, 0 Fehler, Temperatur OK ✓
→ 600MHz (+10) - stabil, +2°C, 0 Fehler, Temperatur OK ✓
→ a) 610MHz (+10) - instabil (Fehler oder Hashrate sinkt), Temperatur OK, x
→ b) 610MHz (+10) - stabil, Temperatur zu hoch, x

a) ihr müsst die ASIC Spannung um 10mv erhöhen und nochmals testen
b) ihr müsst für eine bessere Kühlung sorgen

Schritt 5: Instabilität erkennen und beheben

Wenn ihr nach 30 Minuten bei der neuen Frequenz Fehler oder niedriger Hashrate seht:

Diagnose:

• Die aktuelle Frequenz ist an der Grenze der Stabilität der Spannung
• ihr benötigt mehr Spannung, um diese Frequenz stabil zu halten
• ihr benötigt eine bessere Kühlung

Maßnahme: Core Voltage erhöhen

1. Erhöhe die Core Voltage um +10mV (z.B. 1150 → 1160mV) für die instabilen Chips
2. Speichern & Neustart
3. Monitort erneut (mindestens 30 Minuten)
4. Sehr wichtig: Monitor die Temperatur intensiv!
   • Eine Spannungserhöhung erzeugt disproportional mehr Wärme
   • Beispiel: +10mV könnte +3–4°C an Temperatur hinzufügen

Szenario-Beispiel:

Versuch: 610MHz @ 1150mV
→ Nach 10min: 50 Invalid Shares, Hashrate sinkt

Lösung: 610MHz @ 1160mV (Spannung +10mv)
→ Nach 30min: 0 Fehler, aber Temp ist von 60°C auf 65°C gestiegen ✓
→ Akzeptabel! Speichern.

Nächster Versuch: 620MHz @ 1160mV
→ Nach 15min: Neue Fehler, 645 Invalid Shares
→ Wieder Spannung erhöhen? Vielleicht nicht. Temp ist bereits bei 65°C.
→ Lieber bei 610MHz @ 1160mV stoppen.

In meinem Falle ist aufgrund der besseren Kühlung das Gerät immer noch bei 60°, aber der Lüfter dreht schon deutlich schneller bei 54%

Schritt 6: Überhitzung erkannt? (Stop!)

Wenn während eines Versuches die Temperaturen in den gefährlichen Bereich schießen:

Sichere Schwellenwerte (harte Limiten):

• ASIC Core Temp > 70°C: Gefährliche Zone. Der Chip kann sich automatisch abschalten.
• VRM Temp > 85°C: Kritisch. Mehr Airflow ist notwendig

Wenn ihr dies seht: sofort stoppen!

Maßnahme: Rollback

1. Revertiert die letzte Frequenz- oder Spannungserhöhung, die diese Temperaturen ausgelöst hat
   • Wenn die Temp bei 620MHz zu hoch wurde, gehe zurück auf 610MHz
   • Oder wenn die Temp bei 1170mV stieg, geht zurück auf 1160mV
2. Speichert & Startet erneut, verifiziert, dass Temps zurück zu sicheren Werten gehen
3. Danach: Um weiter zu gehen, benötigt ihr Kühlungs-Upgrades:
   • Bessere/stärkere Ventilatoren
   • Niedrigere Umgebungstemperatur
   • Flüssigkeitskühlung (für extreme OC)
   • Bessere Airflow-Umgebung

Warnung: Das Ignorieren von Temperaturwarnungen ist der sicherste Weg zu permanenten Hardware-Schäden oder Bränden. Respektiert die Grenzen.

Schritt 7: Die OC-Grenze finden

Wiederholt diese Zyklen (Freq erhöhen → Monitoren → Falls instabil, Spannung erhöhen → Monitoren temps):

Ihr stoppt, wenn eine der folgenden Bedingungen erfüllt ist:

1. Ihr hast dein Ziel-Performance-Level erreicht
   • Z.B. wolltet ihr 20% mehr Hashrate, und ihr habt sie erreicht bei akzeptablen Temps & Spannungen ✓
2. Instabilität lässt sich nicht mit mehr Spannung beheben
   • Z.B. bei 700MHz @ 1200mV ist immer noch instabil bei 700MHz @ 1250mV
   • Das bedeutet: Die Hardware kann diese Frequenz physikalisch nicht stabil halten (selbst mit höherer Spannung)
   • Das ist die Hardware-Grenze
3. Thermische Grenzen erreicht
   • ASIC Temps sind konsistent > 70°C
   • VRM Temps nähern sich 85°C
   • Weitere Erhöhungen würden zu Shutdowns oder Schäden führen

Die "ideale" OC-Zone:

• Frequenz-Gewinn: +10–15% über Baseline (z.B. 550 → 610MHz) ist "konservativ"
• Spannungs-Erhöhung: +20–30mV über Baseline ist "moderat"
• Temperatur-Erhöhung: +15°C über Baseline wird noch akzeptiert
• Alles darüber: Aggressives OC mit hohem Risiko

Die perfekte OC-Einstellung finden: Ein vollständiges Beispiel

Angenommen, eure Baseline ist:

Frequency: 550MHz
Core Voltage: 1150mV
Temp: 60°C
Hashrate: 1070 GH/s (100%)
Power Draw: 18
Efficiency: 16.0 J/TH
Standard Kühlblock und Lüfter

OC-Versuch Gerät Nummer 1 mit Standard Kühler, schlechter ASIC Chip:

Fazit: Optimales OC-Fenster liegt bei 590 MHz @ 1160 mV

Warum Schritt 3 statt Schritt 5?

Während Schritt 5 (630 MHz @ 1170 mV) die höchste Hashrate von 1300 GH/s erreicht, ist dies nicht das beste Gesamtpaket:

• Stabilität: Schritt 3 ist vollständig stabil (0 Fehler), Schritt 5 ist nur Borderline
• Temperatur: 63°C vs. 68°C – noch im grünen Bereich
• Effizienz: 17.0 J/TH ist deutlich besser als 19.0 J/TH bei Schritt 5
• Hashrate-Gewinn: +6,4% gegenüber Schritt 1 (1100 → 1170 GH/s)
• Stromeffizienz: +2W mehr Verbrauch, aber stabiles System

Schritt 5 als risikobereite Alternative:

• +18,2% Hashrate (1300 GH/s)
• Aber: Borderline-Status, höhere Temps, schlechtere Effizienz
• Nur für aggressive Mining-Szenarien ohne Langzeitstabilität gefordert

OC Versuch Gerät Nummer 2 mit The Bitchin' Sink Kühler und dem Gelid Black Magic und zusätzlichen Effizienz Tuning

Fazit: OC-Versuch Gerät Nummer 2 – Optimales Fenster bei 640 MHz @ 1130 mV

Dieser Versuch zeigt deutlich bessere Ergebnisse als der erste. Mit dem The Bitcoins Sink Kühler und dem Gelid Black Magic Lüfter erreichen wir maximale Performance bei minimaler Spannung.

Optimaler Betriebspunkt: Schritt 8 / Schritt 10 (identisch)

• Hashrate: 1.31 TH/s (+22,4% vs. Baseline)
• Spannung: 1130 mV (deutlich niedriger als Schritt 6!)
• Temperatur: 60°C (sehr kühl)
• Stromverbrauch: 19.5W (sehr effizient)
• Effizienz: 18.5 J/TH
• Status: ✓ OK (vollständig stabil)

Warum besser als Schritt 6? Beide erreichen 1.31 TH/s, aber:

• Schritt 6: 1150mV, 23W, 20.0 J/TH
• Schritt 8/10: 1130mV, 19.5W, 18.5 J/TH

Mit 20mV weniger Spannung spart ihr 3.5W Stromverbrauch und verbessert die Effizienz um 7,5%. Das ist die perfekte Kurve für Langzeitbetrieb.

Grenzbereich erkannt: Schritt 9 (1120mV) zeigt Instabilität – 1130mV ist die sichere Untergrenze.

Fazit: Der bessere Kühler ermöglicht deutlich aggressiveres Tuning mit gleichzeitig besserer Effizienz. Das ist ein sehr sauberes Ergebnis.

Die Realität der OC-Risiken

1. Die Risiken sind real:
   • Potentielle Belohnung (höhere Hashrate) kommt mit erheblichen Risiken
   • Permanente Hardware-Schäden möglich
   • Brandgefahr durch Überhitzung
   • Herstellergarantie oft ungültig nach OC
2. Effizienz ist King:
   • Höhere Frequenz und Spannung erhöhen den Stromverbrauch drastisch
   • Berechnet: Kostet mich der Extra-Strom mehr als die Extra-Bitcoin-Hashrate wert ist?
   • Beispiel: +30% Strom für +10% Hashrate = schlechtes Geschäft
3. Stromqualität ist entscheidend:
   • In Regionen mit instabilen Stromnetzen (Brownouts, Spitzen, Solar/Wind-Fluktuationen) NICHT ÜBERTAKTEN
   • Instabile Stromversorgung während OC ist ein Sicherheitsrisiko
   • Investiere in hochwertige Stromversorgungen (Modularität, Überlastschutz, bessere Netzteile)
4. Umgebungsfaktoren:
   • In heißem Klima (>30°C Umgebungstemperatur): Sehr konservativ mit OC
   • In kaltem Klima (<15°C): Mehr Spielraum für OC
   • Raumluftqualität (Staub, Verschmutzung) wirkt sich auf Kühlung aus

Best Practices für sichere OC

✅ DO:

• Startet mit sehr kleinen Inkrementierungen (+5 MHz / +5mV wenn ihr sehr vorsichtig sein möchtet)
• Monitort obsessiv – mehrere Stunden lang, nicht nur 30 Minuten
• Setzt neue Einstellungen nicht über die Nacht, sondern eher am Tag wenn ihr das Gerät überwachen könnt
• Dokumentiert alles (Einstellungen, Temperatures, Fehlerate, Hashrate) für zukünftige Referenz
• Prioritäre Stabilität > Performance
• Haltet Backups eurer aktuellen stabilen Konfiguration

❌ DON'T:

• Vertraut nicht auf "Online-OC-Rechner" – das beste OC für euren Miner müsst ihr empirisch finden
• Erhöht nicht Freq UND Volt gleichzeitig – ihr wisst nicht, was was verursacht hat
• Ignoriert Temperaturwarnungen
• Verzweiflet nicht bei Fehlern – sie sind normal bei der OC-Grenze

Teil 2: Undervolting - Effizienz steigern und Lautstärke reduzieren

Was ist Undervolting

Während Overclocking die Hashrate maximiert, reduziert Undervolting die Spannung, um den Stromverbrauch zu senken. Das Beste: Undervolting ist sicher - es kann die Hardware nicht beschädigen. Treten Fehler auf oder sinkt die Hashrate zu stark, könnt ihr problemlos zur vorherigen Einstellung zurückkehren.

Warum Undervolting?

• Deutlich geringerer Stromverbrauch (10-20%)
• Niedrigere Temperaturen (5-15°C)
• Leiser Betrieb (niedrigere Lüftergeschwindigkeit)
• Längere Hardware-Lebensdauer als Bonus

Der Physik-Trick: Die Leistungsaufnahme steigt quadratisch mit der Spannung: P ≈ V² × f

• -10% Voltage = ca. -19% Stromverbrauch
• -15% Voltage = ca. -28% Stromverbrauch

Beispiel: BitAxe Undervolting

Ausgangssituation:

• Frequenz: 550 MHz
• Voltage: 1.15V (1150mV)
• Verbrauch: 18.7W
• Temperatur: 60°C
• Lüfter: 42%

Ziel:

• Verbrauch reduzieren
• Temperaturen senken
• Lüfter leiser bekommen

Der Undervolting-Prozess (Schritt für Schritt)

Schritt 1: Baseline dokumentieren

Notiert die aktuellen Werte:

• Voltage: 1150mV
• Frequency: 550 MHz
• Hashrate: z.B. 1070 GH/s (je nach Chip)
• Stromverbrauch: 18.7W
• Temperatur: 64-68°C
• Lüfter: 100%

Schritt 2: Erste Voltage-Reduktion

Konservativer Start: -25mV

• Neue Einstellung: 1100mV (1.10V)
• Frequenz bleibt bei 550 MHz
• Speichern und Neustart

Alternative - Aggressiver: -50 bis -75mV

• Bei BitAxe mit schlechter Kühlung oft möglich
• Neue Einstellung: 1100mV oder 1075mV

Schritt 3: Monitoring (30-60 Minuten)

Was prüfen:

• ✅ Läuft der Chip stabil? (keine Abstürze)
• ✅ Hashrate im erwarteten Bereich? (±2-3% ist okay)
• ✅ Temperatur gesunken? (sollte 3-8°C niedriger sein)
• ✅ Lüfter langsamer/leiser? (sollte automatisch runterregeln bei niedrigerer Temp)

Erfolgs-Indikatoren:

• Chip läuft ohne Fehler
• Hashrate nur minimal reduziert (0-5%)
• Temperatur deutlich niedriger (60°C oder weniger)
• Lüfter läuft bei 70-85% statt 100%
• Stromverbrauch: 14-16W statt 18W

Warnsignale:

• Häufige Hardware-Errors
• Hashrate bricht um >10% ein
• Chip wird instabil oder resettet

Schritt 4: Weiter optimieren (optional)

Wenn Schritt 2 erfolgreich war, könnt ihr weitermachen:

Nächster Schritt: weitere -10mv reduzieren

• Beispiel: Von 1100mV auf 1090mV
• Wieder 30Min testen

Typische BitAxe Sweet Spots:

• Konservativ: 1100mV (-50mV): ~16W, 62°C, Lüfter 85%
• Balanced: 1100-1050mV (-50 bis -100mV): ~14-15W, 58-60°C, Lüfter 70-80%
• Aggressiv: 1050-1030mV (-150 bis -170mV): ~12-13W, 55°C, Lüfter 60-70%
  • Achtung: Kann zu instabil sein, Hashrate-Verlust 5-10%

Schritt 5: Finales Testing

Nach 24 Stunden Laufzeit:

• Ist der Betrieb stabil geblieben?
• Keine ungewöhnlichen Fehler?
• Temperaturen konstant?

Falls instabil: Voltage um +10-20mV erhöhen

Die Bitaxe mit den neuen Settings:

Frequency + Voltage Co-Tuning

Für maximale Effizienz könnt ihr beides anpassen:

Beispiel:

• Voltage: 1025mV (-125mV)
• Frequency: 525 MHz (-25 MHz)

Ergebnis:

• Verbrauch: ~14W (-33%)
• Temperatur: ~52-55°C
• Lüfter: 30% (sehr leise!)
• Hashrate: ~1070 GH/s (-11%)

Wann sinnvoll:

• Lautstärke ist Hauptproblem
• Kühlung ist limitierend
• Hobby-Mining, Hashrate zweitrangig

Troubleshooting

Problem: Chip wird instabil → Voltage um +20mV erhöhen

Problem: Hashrate bricht stark ein (>10%) → Zu aggressives Undervolting, +10-20mV zurück

Problem: Temperatur sinkt kaum → Wärmeleitpaste prüfen, Kühler reinigen, mehr Voltage-Reduktion

Problem: Lüfter läuft weiter bei 100% → Lüfter-Steuerung prüfen

Wichtige Hinweise

✅ Sicher:

• Undervolting beschädigt Hardware nicht
• Jederzeit rückgängig machbar
• Keine langfristigen Risiken

✅ Vorteile:

• Deutlich leiser (Hauptziel bei BitAxe!)
• Weniger Stromkosten
• Kühlerer Betrieb
• Längere Lebensdauer

⚠️ Beachten:

• Jeder Chip ist anders (Silizium-Lotterie)
• Testet in kleinen Schritten
• 24h-Test für finale Settings
• Bei Instabilität einfach zurück zur vorherigen Einstellung

Teil 3: Beheben von niedriger Hashrate & Instabilität (Tuning Up)

Diagnose: Wo liegt das Problem

Wenn euer Miner Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "Summit-Fehler") von spezifischen Chips oder dem gesamten Gerät zeigt, oder die Hashrate deutlich unter den Spezifikationen liegt:

Mögliche Ursachen:

1. Unzureichende Spannung für die aktuelle Frequenz (häufigste Ursache)
2. Schlechte thermische Anbindung (Chip überhitzt lokal)
3. Fehlerhafte Chip/Hashboard
4. Instabile Stromversorgung
5. Firmware-Bug oder falsche Pool-Konfiguration

Ziel dieses Teils

Finde die minimale stabile Spannung, die alle Fehler eliminiert und die erwartete Hashrate bei der aktuellen Frequenz wiederherstellt. Dies optimiert die Energieeffizienz (J/TH) und redzuiert die Fehlerrate.

Der sichere Tuning-Prozess

Schritt 1: Diagnose & Identifikation

Nutzt eurer Miner-Management-Interface (AxeOS, Braiins OS+, StockOS, etc.) um zu überprüfen:

• Expected Hashrate: Stimmt die Tatsächliche Hashrate mit der Exptected Hashrate überein?
• Submission Rate: Wie viele gültige Shares sendet jeder Chip?

Schritt 2: Baseline dokumentieren

Notiert die aktuellen Einstellungen für alle Chips oder Problem-Chips:

• Core Voltage: z.B. 1150mV
• Frequency: z.B. 550MHz
• Aktuelle Hashrate: Notiere die beobachtete Rate
• Fehler-Rate: z.B. 10% Invalid Shares
• Niedrigere Hashrate als die Exptected Hashrate

Schritt 3: Kleine Spannungserhöhung

Erhöht die Core Voltage für die problematischen Chips um +5mV (z.B. von 1150mV auf 1155mV).

Schritt 4: Speichern & Neustart

• Speichert die neuen Einstellungen im Miner-OS
• Führt einen vollständigen Neustart durch
  • Dies stellt sicher, dass alle Komponenten mit den neuen Parametern initialisiert werden
  • Verhindert Fehler durch Cache oder teilweise geladene Konfigurationen

Schritt 5: Intensives Monitoring (15-30+ Minuten)

Beobachtet folgende Metriken sehr genau:

5a) Submission Rate & Hashrate

• Haben die Fehlerquoten ("Invalid Shares", "HW Errors") abgenommen?
• Ist die beobachtete Hashrate jetzt näher an der erwarteten Hashrate für diese Frequenz?
• Beispiel: Bei 625MHz solltet ihr die gleiche Hashrate sehen wie zuvor, nur ohne Fehler

5b) Temperatur

• Sind die ASIC-Core-Temperaturen angestiegen? (Ja, aber wie viel?)
• Erwartungswert: +1–3°C pro +10mV Spannungserhöhung ist typisch
• Überwachung kritischer Schwellenwerte:
  • ASIC Temp nicht über 70
  • VRMs (Voltage Regulators) < 95°C

5c) Hardware Errors

• Erscheinen neue oder verschiedene Fehlertexte im Log?
• nonce_range_err: Könnte auf Stromprobleme hindeuten

Wo man nach Logs sucht:

• AxeOS: Web-Interface > Logs > Download Full Log oder im Dashboard
• NerdQ OS: Miner > Log Viewer im Web-Interface

Schritt 6: Iterieren (falls nötig)

Wenn die Fehlerquoten nach 30 Minuten Monitoring immer noch hoch sind:

1. Wiederhole Schritt 3: Erhöhe die Spannung um weitere +10mV (z.B. 1160 → 1170mV)
2. Führe Schritte 4 & 5 erneut durch
3. Wichtig: Gehe schrittweise vor! Nicht in 50mV-Sprüngen erhöhen.

Typische Progression bei Problemen:

1150mV → 50% Fehler → 1160mV → 20% Fehler → 1170mV → 5% Fehler → 1180mV → 0% Fehler ✓

Schritt 7: Diagnose eines Defekts

Wenn ihr nach mehreren Inkrementierungen (z.B. bis 1200–1200mV) immer noch keine Verbesserung siehst, liegt das Problem wahrscheinlich nicht an der Spannung oder der Chip ist wirklich kein Silikon Lottery Win:

Mögliche Probleme:

1. Defekter Chip/Board: Das Hashboard könnte physikalisch beschädigt sein
2. Schlechte Wärmeableitung: Wärmepaste ist trocken oder wurde falsch aufgetragen
3. Schlechte Stromversorgung zu diesem Board: Beschädigtes Stromleitungskabel oder Stecker
4. Firmware-Bug: Seltener, aber möglich
5. ASIC Binning: sehr schlechte ASIC Qualität

Diagnose-Schritte:

• Extrahiert die vollständigen Logs und teilt sie mit der Community
• Wenn thermisch: Überprüft die Wärmepaste-Konsistenz und Aufpressdruck
• Im Extremfall: Wechsel das Board oder den Chip aus, oder sendet das Gerät zurück wo ihr es gekauft habt

Fazit

Nutzt dieses Wissen weise. Beginnt klein, überwacht obsessiv, priorisiert Stabilität und Kühlung, und respektiert immer die Grenzen der Hardware. Glücklich (und sicheres) Mining! ⛏️

Bei der praktischen Umsetzung zeigt sich häufig: Ein OC lässt sich in den meisten Fällen rückgängig machen und die Hardware wird wieder normal, solange keine Überhitzung stattgefunden hat. Wenn die Hardware nicht physikalisch beschädigt wurde, könnt ihr zu den Werkseinstellungen zurückkehren – allerdings sind thermische oder elektrische Schäden oft permanent.

Ein wichtiger Punkt: Unterschiedliche Chip-Generationen (BM1368, BM1370, etc.) sollten praktisch nicht mit denselben Einstellungen getuned werden. Während es theoretisch möglich ist, haben unterschiedliche Generationen unterschiedliche Optimalpunkte. Nutzt separate Einstellungen pro Generation, wenn möglich.

Im Shop verkaufen wir Geräte, welche in der PowerSave Edition auf maximale Effizienz, und in der Special beziehungsweise Black Edition auf Leistungsfähigkeit bei angepasster Chipspannung und Chipfrequenz optimiert worden sind, ohne dass ihr die Garantie verliert. Schaut mal vorbei!

The post Tuning & Overclocking Guide für Bitaxe und NerdQ Miner appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Antwort auf diese Fragen ist differenzierter, als es die mediale Berichterstattung vermuten lässt. Dieser Artikel nimmt eine technische Einordnung der BKA-Operation vor und zeigt auf, warum Timing-Attacken zwar theoretisch möglich, in der Praxis aber äußerst aufwendig und für die allermeisten Tor-Nutzer kein realistisches Risiko darstellen.

Was ist eine Timing-Attacke

Um zu verstehen, was bei der BKA-Operation tatsächlich passiert ist, muss man zunächst das Grundprinzip einer Timing-Attacke verstehen. Tor funktioniert, indem es den Datenverkehr der Nutzer durch mehrere Server (sogenannte Relays oder Nodes) leitet, typischerweise über eine Kette von mindestens drei Servern:

1. Entry Node (Guard): Der erste Server, mit dem der Nutzer sich verbindet
2. Middle Node: Ein oder mehrere Zwischenserver
3. Exit Node: Der letzte Server, der die Anfrage ins "normale" Internet (Clearnet) weiterleitet

Jede Verbindungsschicht ist verschlüsselt, sodass kein einzelner Server die gesamte Verbindung sehen kann. Das ist das Kernprinzip von Tor: Kein einzelner Akteur soll gleichzeitig wissen, wer etwas sendet und wohin es gesendet wird.

Eine Timing-Attacke versucht nun, diese Trennung aufzuheben, indem sie Datenpakete zeitlich korreliert. Die grundlegende Idee ist simpel: Wenn ein Angreifer sowohl den Entry Node als auch den Exit Node kontrolliert (oder zumindest überwachen kann), kann er die Zeitstempel der ein- und ausgehenden Datenpakete vergleichen. Stimmen die Timing-Muster überein, lässt sich mit hoher Wahrscheinlichkeit ableiten, dass beide Datenpakete zur selben Verbindung gehören.

Mathematisch und praktisch betrachtet

Forscher haben gezeigt, dass bereits einfache statistische Methoden wie die Analyse von Paket-Interarrival-Zeiten (die Zeit zwischen aufeinanderfolgenden Paketen) ausreichen können, um Verbindungen zu korrelieren. Algorithmen wie Mutual Information oder Frequency Analysis können verwendet werden, um charakteristische "Fingerabdrücke" im Datenverkehr zu identifizieren.

Konkret funktioniert eine Timing-Attacke in mehreren Schritten:

1. Beobachtungsphase: Der Angreifer zeichnet über einen längeren Zeitraum Timing-Daten auf beiden Seiten auf – am Entry Node und am Exit Node (oder am Ziel-Server).
2. Muster-Extraktion: Aus den Rohdaten werden charakteristische Merkmale extrahiert:
   • Paketgrößen-Verteilung
   • Burst-Muster (wann werden viele Pakete auf einmal gesendet?)
   • Interarrival-Zeiten (Abstände zwischen Paketen)
   • Gesamtvolumen über Zeitfenster
   • Directional patterns (Upload vs. Download Verhältnisse)
3. Korrelationsanalyse: Statistische Verfahren vergleichen die Muster von verschiedenen Verbindungen. Je höher die Übereinstimmung, desto wahrscheinlicher gehören beide Seiten zusammen.
4. Konfidenz-Berechnung: Durch wiederholte Messungen und längere Beobachtungszeiträume kann die Sicherheit der Zuordnung erhöht werden.

Das Problem: Diese Attacken funktionieren umso besser, je mehr Traffic ein Angreifer überwachen kann und je weniger andere Verbindungen parallel laufen. Bei einem Netzwerk mit Millionen von Nutzern und tausenden von Nodes wird die Sache schnell kompliziert.

Ein praktisches Beispiel verdeutlicht die Komplexität: Stellt euch vor, ihr beobachtet einen Entry Node mit 100 aktiven Verbindungen und einen Exit Node mit 80 aktiven Verbindungen. Rein mathematisch ergeben sich daraus 8.000 mögliche Verbindungskombinationen. Selbst mit perfekten Timing-Daten ist es nicht trivial, die richtigen Paare zu finden – besonders wenn mehrere Nutzer gleichzeitig ähnliche Websites besuchen oder ähnliche Traffic-Muster erzeugen.

Die BKA-Operation im Detail

Was wissen wir?

Laut dem Panorama-Bericht und den Recherchen des Chaos Computer Clubs (CCC) hat das BKA zwischen 2019 und 2021 Timing-Attacken durchgeführt, um den Administrator der Darknet-Plattform "Boystown" zu identifizieren. Die Details der Operation wurden nie vollständig offengelegt, aber aus den verfügbaren Informationen lässt sich Folgendes rekonstruieren:

1. Das BKA betrieb oder überwachte mehrere Tor-Nodes, sowohl Entry- als auch Middle-Nodes
2. Die Zielperson nutzte eine veraltete Version der Software Ricochet, eines anonymen Chat-Programms, das über Tor läuft
3. Durch wiederholte Verbindungsversuche erzwang das BKA, dass die Zielperson neue Tor-Circuits aufbaute
4. Statistisch war es nur eine Frage der Zeit, bis einer dieser Circuits durch einen vom BKA kontrollierten Middle Node lief
5. Sobald dies der Fall war, konnte das BKA durch Timing-Analyse den verwendeten Guard Node identifizieren
6. Vom Guard Node aus konnte das BKA bei Telefónica (O2) die IP-Adresse des Nutzers erfragen

Der entscheidende Schwachpunkt: Veraltete Software

Das Tor Project selbst geht davon aus, dass die Deanonymisierung primär deshalb gelang, weil der Administrator eine veraltete Version von Ricochet verwendete, die vor 2022 entwickelt wurde. Diese Version enthielt noch keine Vanguards-lite-Technologie, die speziell gegen solche Guard-Discovery-Attacken entwickelt wurde.

Vanguards-lite funktioniert, indem es die Auswahl der Middle Nodes nicht mehr vollständig zufällig erfolgen lässt, sondern ein Set von festen "Vanguard"-Nodes definiert, die rotiert werden. Dadurch wird das "unendliche Würfelspiel" eliminiert, bei dem ein Angreifer einfach nur lange genug warten muss, bis sein kompromittierter Node ausgewählt wird.

Es ist deshalb spannend zu sehen, wie die meissten staatstreuen Medien von einem "schweren Schlag für das Tor Project" sprechen, obwohl der das Problem eigentlich der veraltet Ricochet Messenger das Problem war.

Der NDR sprach auch von einer erfolgreichen Unterwanderung von Tor, spricht aber auch nur die nur einen Bruchteil der wirklichen Geschehnisse an:

https://www.ndr.de/fernsehen/sendungen/panorama/aktuell/Anonymisierungsdienst-Tor-angreifbar-Snowden-Effekt-verpufft,tor192.html

Der entscheidende Unterschied: Exit Nodes vs. Onion Services

Hier kommen wir zum Kern der Sache, der in der Berichterstattung oft untergeht: Die beschriebene Timing-Attacke funktioniert primär bei Verbindungen ins Clearnet, also wenn ein Exit Node verwendet wird.

Warum Exit Nodes das Problem sind

Wenn Nutzer über Tor auf normale Websites zugreifen (z.B. google.com oder wikipedia.org), verlässt ihr Datenverkehr das Tor-Netzwerk am Exit Node. An diesem Punkt ist der Datenverkehr entschlüsselt (zumindest soweit keine zusätzliche TLS-Verschlüsselung verwendet wird) und kann von einem Angreifer, der den Exit Node kontrolliert, vollständig eingesehen werden.

Kontrolliert ein Angreifer nun sowohl den Entry Node als auch den Exit Node, kann er:

• Am Entry Node sehen, wann bestimmte Datenpakete ins Tor-Netzwerk eingespeist werden
• Am Exit Node sehen, wann Datenpakete das Netzwerk verlassen und wohin sie gehen
• Durch Timing-Korrelation beide Enden der Verbindung zusammenführen

Onion-zu-Onion: Eine andere Liga

Die Situation ändert sich dramatisch, wenn man ausschließlich innerhalb des Tor-Netzwerks bleibt, also auf .onion-Websites (Hidden Services/Onion Services) zugreift. In diesem Fall:

1. Es gibt keinen Exit Node – die Verbindung verlässt das Tor-Netzwerk niemals
2. Beide Seiten sind anonymisiert – sowohl der Client als auch der Server sind über Tor erreichbar
3. Die Verbindung erfolgt über einen Rendezvous Point – einen neutralen Treffpunkt im Netzwerk
4. Ende-zu-Ende-Verschlüsselung bleibt durchgehend bestehen

Für eine erfolgreiche Timing-Attacke müsste ein Angreifer in diesem Szenario:

• Entweder den Guard Node des Clients UND den Guard Node des Servers kontrollieren
• Oder einen komplexeren Sybil-Angriff durchführen, bei dem er einen signifikanten Teil des Netzwerks kompromittiert

Das ist um Größenordnungen schwieriger als die "simple" Entry-Exit-Korrelation.

Warum Timing-Attacken kein Alltag sind

Ressourcenaufwand

Timing-Attacken sind keine "Script-Kiddie"-Angriffe. Sie erfordern:

1. Infrastruktur: Der Angreifer muss mehrere Tor-Nodes betreiben oder Zugriff auf die Netzwerkinfrastruktur großer ISPs haben
2. Zeit: Die Attacke kann Wochen oder Monate dauern, besonders bei Zielpersonen mit unregelmäßiger Aktivität
3. Rechenleistung: Die Korrelation von Millionen von Datenpaketen über tausende von Verbindungen erfordert erhebliche Rechenkapazität
4. Spezifisches Targeting: Man kann nicht einfach "alle Tor-Nutzer" deanonymisieren – jede Person muss individuell verfolgt werden

Staatliche Ressourcen erforderlich

Die BKA-Operation zeigt deutlich: Timing-Attacken sind ein Werkzeug, das realistisch nur von staatlichen Akteuren mit erheblichen Ressourcen eingesetzt werden kann. Ein durchschnittlicher Cyberkrimineller, eine Hackergruppe oder selbst ein Unternehmen haben nicht:

• Die rechtlichen Möglichkeiten, ISPs zur Herausgabe von IP-Adressen zu zwingen
• Die Infrastruktur, um dutzende Tor-Nodes zu betreiben
• Die Zeit und Geduld, eine monatelange Überwachung durchzuführen
• Das technische Know-how für hochkomplexe Traffic-Korrelations-Algorithmen

Statistik und Wahrscheinlichkeit

Das Tor-Netzwerk besteht Stand 2025 aus:

• Etwa 8.000 aktiven Relays
• Davon circa 2.500 Exit Nodes
• Über 2 Millionen täglichen Nutzern

Die Wahrscheinlichkeit, dass ein durchschnittlicher Tor-Nutzer zufällig eine Verbindung aufbaut, bei der sowohl Entry als auch Exit Node von einem Angreifer kontrolliert werden, ist extrem gering. Selbst wenn ein Angreifer 10% aller Nodes kontrollieren würde (was eine massive Investition wäre), läge die Wahrscheinlichkeit bei etwa 1%.

Für die überwiegende Mehrheit der Tor-Nutzer – Aktivisten, Journalisten, Menschen in repressiven Regimen, Privacy-Enthusiasten – sind Timing-Attacken kein realistisches Bedrohungsszenario.

Tor's Verteidigungsmaßnahmen

Das Tor Project arbeitet kontinuierlich daran, das Netzwerk gegen verschiedene Angriffsformen zu härten. Seit der Zeitperiode der BKA-Operation (2019-2021) wurden mehrere wichtige Verbesserungen implementiert:

1. Vanguards-lite (seit Juni 2022)

Vanguards-lite ist die wichtigste Gegenmaßnahme gegen Guard-Discovery-Attacken. Das System funktioniert wie folgt:

• Statt bei jedem Circuit-Aufbau zufällig neue Middle Nodes zu wählen, verwendet Tor einen Pool von 4 Layer-2-Guards
• Diese Guards werden über einen Zeitraum von etwa 2 Wochen verwendet (mit einer max(X,X)-Verteilung zwischen 1 und 22 Tagen)
• Dadurch wird die Wahrscheinlichkeit drastisch reduziert, dass ein Angreifer durch wiederholte Verbindungsversuche einen seiner Nodes in die Circuit-Kette bekommt

Vanguards-lite ist seit Tor 0.4.7 standardmäßig aktiviert für alle Onion-Service-Aktivitäten.

2. Full Vanguards (optional)

Für besonders sicherheitsbewusste Onion-Service-Betreiber gibt es "Full Vanguards", ein noch strengeres System:

• Es fügt eine dritte Layer von Guard-Nodes hinzu
• Circuits werden dadurch länger (mehr Hops), was die Latenz erhöht
• Die Rotation erfolgt über längere Zeiträume (Wochen bis Monate)
• Geeignet für langlebige, hochsichere Services

3. Circuit Padding und Timing-Obfuscation

Tor experimentiert mit verschiedenen Techniken, um Timing-Muster zu verschleiern:

• Packet Padding: Hinzufügen von Dummy-Daten, um Paketgrößen zu verschleiern
• Delayed Transmission: Künstliche Verzögerungen beim Senden von Paketen, um Timing-Muster aufzubrechen
• Traffic Morphing: Umformung von Traffic-Mustern, damit sie wie normaler HTTPS-Traffic aussehen

Diese Techniken befinden sich teilweise noch in der Forschungs- und Entwicklungsphase, da sie immer einen Trade-off zwischen Sicherheit und Latenz darstellen.

4. Netzwerk-Diversität

Das Tor Project arbeitet aktiv daran, die Diversität des Netzwerks zu erhöhen:

• Geografische Verteilung: Mehr Relays in verschiedenen Ländern
• Autonomous System (AS) Diversität: Verteilung über verschiedene ISPs und Hosting-Provider
• Malicious Relay Detection: Automatische Erkennung und Entfernung verdächtiger Nodes

5. Verbessertes Relay-Monitoring

Seit 2021 wurden die Mechanismen zur Erkennung von Angriffen deutlich verbessert:

• Anomalie-Erkennung bei Circuit-Patterns
• Überwachung von ungewöhnlichen Relay-Verhaltensweisen
• Schnellere Reaktion auf Sybil-Attacken (bei denen ein Angreifer viele Nodes auf einmal ins Netzwerk einschleust)

Praktische Empfehlungen für Tor-Nutzer

Was schützt zusätzlich?

1. Tor Browser immer aktuell halten: Die neuesten Versionen enthalten alle Sicherheitsverbesserungen. Der Tor Browser aktualisiert sich in der Regel automatisch, aber es schadet nicht, regelmäßig zu überprüfen, ob ihr die neueste Version verwendet.
2. Onion Services bevorzugen: Wann immer möglich, .onion-Versionen von Websites nutzen. Viele große Plattformen bieten mittlerweile Onion-Versionen an:
   • New York Times: https://www.nytimes3xbfgragh.onion
   • ProPublica: https://p53lf57qovyuvwsc6xnrppyply3vtqm7l6pcobkmyqsiofyeznfu5uqd.onion
   • BBC: https://www.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion
   • DuckDuckGo: https://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
3. Bridges verwenden: Besonders in Regionen mit Tor-Blocking können Bridges zusätzliche Anonymität bieten. Sie verschleiern zusätzlich, dass ihr überhaupt Tor verwendet. Typen von Bridges:
   • obfs4: Verschleiert Tor-Traffic als normalen HTTPS-Traffic
   • Snowflake: Verwendet kurzlebige Proxys in Browsern freiwilliger Helfer
   • meek: Tarnt Tor-Traffic als normale Verbindungen zu großen Cloud-Diensten (Azure, Google)
4. Mehrschichtige Sicherheit: Kombiniert Tor mit anderen Privacy-Tools:
   • VPN + Tor (umstritten, aber in manchen Szenarien sinnvoll)
   • Tails OS (ein komplettes Betriebssystem, das nur über Tor kommuniziert)
   • Whonix (isoliert den Tor-Client in einer separaten VM)
5. Keine persönlichen Informationen preisgeben: Die beste technische Sicherheit nützt nichts, wenn man sich selbst identifiziert:
   • Verwendet keine Accounts, die mit eurer realen Identität verknüpft sind
   • Achtet auf Metadaten in hochgeladenen Dateien (EXIF-Daten in Fotos!)
   • Vermeidet charakteristische Schreibstile oder Formulierungen
   • Nutzt keine personalisierten Services (Social Media, Cloud-Storage)
6. Langlebige Verbindungen vermeiden: Je länger eine Verbindung besteht, desto mehr Daten stehen für Korrelationsangriffe zur Verfügung. Das Tor-Netzwerk wechselt automatisch alle 10 Minuten die Circuits, aber bei sehr langen Sessions (mehrere Stunden) sollte man den Browser neu starten.
7. JavaScript mit Bedacht verwenden: Der Tor Browser bietet verschiedene Sicherheitsstufen:
   • Standard: JavaScript aktiviert (für normale Websites)
   • Safer: JavaScript auf HTTPS-Sites deaktiviert, wo nicht unbedingt nötig
   • Safest: JavaScript komplett deaktiviert (sicherste Option, aber viele Websites funktionieren nicht mehr)
8. Sichere Kommunikation über Tor: Wenn ihr über Tor kommuniziert:
   • Verwendet Ende-zu-Ende-verschlüsselte Messenger (Signal über Tor, Ricochet-Refresh)
   • Vermeidet E-Mail über Exit Nodes (nutzt Onion-Mail-Services oder PGP)
   • Seid euch bewusst, dass Exit Nodes unverschlüsselten Traffic mitlesen können

Spezielle Hinweise für hochsensible Anwendungsfälle

Wer wirklich maximale Sicherheit braucht (Whistleblower, Journalisten in Kriegsgebieten, politische Aktivisten unter autoritären Regimen), sollte zusätzlich beachten:

• Dedizierte Hardware: Verwendet einen separaten Computer nur für Tor-Aktivitäten
• Öffentliche Netze: Verbindet euch von wechselnden Orten aus (Cafés, Bibliotheken)
• Timing-Variation: Vermeidet regelmäßige Muster bei der Tor-Nutzung
• Professionelle Beratung: Organisationen wie die Electronic Frontier Foundation (EFF) oder das Tor Project selbst bieten Sicherheitsberatung an

Was ist realistisch gefährlich?

Für die allermeisten Nutzer sind folgende Bedrohungen relevanter als Timing-Attacken:

• Browser-Fingerprinting: Identifizierung durch einzigartige Browser-Konfigurationen
• JavaScript-basierte Angriffe: Ausnutzung von Sicherheitslücken
• Phishing und Social Engineering: Die klassischen menschlichen Schwachstellen
• Exit-Node-Überwachung: Kompromittierte Exit Nodes, die unverschlüsselten Traffic abfangen
• Operational Security (OpSec) Fehler: Versehentliches Preisgeben von Identitätsinformationen

Einordnung der medialen Berichterstattung

Die Berichterstattung über die BKA-Operation war zweifellos wichtig und hat eine berechtigte Diskussion über die Grenzen von Tor angestoßen. Allerdings muss man konstatieren, dass die Darstellung teilweise irreführend war:

Was die Medien richtig berichtet haben:

• Es ist staatlichen Behörden mit erheblichen Ressourcen gelungen, Tor-Nutzer zu deanonymisieren
• Timing-Attacken sind technisch möglich und wurden erfolgreich durchgeführt
• Das Tor-Netzwerk ist nicht absolut unknackbar

Was in der Berichterstattung zu kurz kam:

• Die Attacke richtete sich gegen eine veraltete Software (Ricochet), die seit 2022 durch eine sichere Version ersetzt wurde
• Der enorme Ressourcenaufwand und die Dauer der Operation
• Die spezifischen Umstände (langlebige Verbindung, Onion Service mit niedriger Nutzerzahl)
• Die Tatsache, dass Onion-zu-Onion-Verbindungen deutlich schwerer anzugreifen sind als Clearnet-Verbindungen
• Die zahlreichen Verbesserungen, die Tor seit 2019-2021 implementiert hat

Die Gefahr der Delegitimierung

Es ist nachvollziehbar, dass Berichte über erfolgreiche Deanonymisierungen Unsicherheit erzeugen. Gleichzeitig besteht die Gefahr, dass Menschen, die auf Anonymität angewiesen sind – Whistleblower, Journalisten in autoritären Staaten, Aktivisten – abgeschreckt werden und auf schlechtere oder gar keine Anonymisierungslösungen zurückgreifen.

Die Realität ist: Tor ist nach wie vor das beste verfügbare Werkzeug für Online-Anonymität. Keine andere Technologie bietet eine vergleichbare Kombination aus Benutzerfreundlichkeit, Netzwerkgröße und technischer Robustheit. Perfekt ist es nicht – das ist keine Technologie. Aber für die überwältigende Mehrheit der Bedrohungsszenarien ist Tor mehr als ausreichend.

Die Rolle verschiedener Bedrohungsakteure

Es ist wichtig, zwischen verschiedenen Typen von Angreifern zu unterscheiden:

Globale staatliche Akteure (NSA, BKA, etc.)

Diese haben die Ressourcen für Timing-Attacken, aber:

• Ihre Kapazitäten sind begrenzt
• Sie müssen sich auf hochwertige Ziele konzentrieren
• Sie unterliegen (zumindest in Demokratien) rechtlichen Beschränkungen
• Sie setzen solche Methoden nur bei schweren Verbrechen ein

Autoritäre Regime

Diese können ebenfalls Timing-Attacken durchführen, haben aber oft:

• Weniger technisches Know-how
• Beschränkten Zugriff auf internationale Netzwerkinfrastruktur
• Andere, einfachere Überwachungsmethoden zur Verfügung (z.B. lokale ISP-Überwachung)

Kriminelle und Hackergruppen

Für diese ist eine Timing-Attacke in den allermeisten Fällen:

• Zu aufwendig
• Zu teuer
• Zu zeitintensiv
• Rechtlich zu riskant (eigene Tor-Nodes zu betreiben macht angreifbar)

Unternehmen und Werbeindustrie

Für Tracking-Zwecke sind:

• Browser-Fingerprinting viel effektiver
• Cookie-basierte Methoden ausreichend
• Timing-Attacken völlig unpraktikabel

Technische Entwicklungen und Zukunft

Die Forschung an anonymen Netzwerken steht nicht still. Einige vielversprechende Entwicklungen:

Verbesserte Traffic-Obfuscation

Forscher arbeiten an Systemen wie MUFFLER, die Egress-Traffic dynamisch verschleiern, um Korrelationsangriffe zu erschweren. Der Overhead bleibt dabei minimal – ein entscheidender Faktor für die Praktikabilität.

AI-resistente Anonymität

Interessanterweise könnte KI sowohl Bedrohung als auch Lösung sein:

• Bedrohung: KI-basierte Timing-Analyse könnte präziser werden
• Lösung: KI könnte auch verwendet werden, um Traffic-Muster dynamisch anzupassen und menschliches Verhalten zu simulieren

Quantum-resistente Kryptographie

Obwohl Quantencomputer noch keine unmittelbare Bedrohung darstellen, arbeitet Tor bereits an der Integration von Post-Quantum-Kryptographie, um auch gegen zukünftige Bedrohungen gewappnet zu sein.

Verbesserte Netzwerk-Messungen

Projekte wie FlashFlow haben gezeigt, dass Tor die Kapazität seiner Relays bisher um etwa 50% unterschätzt. Bessere Messungen könnten zu einer deutlich höheren Netzwerk-Performance führen.

Fazit: Tor ist und bleibt sicher

Nach dieser detaillierten technischen Analyse lässt sich festhalten:

1. Timing-Attacken sind möglich, aber alles andere als trivial durchzuführen
2. Sie erfordern massive Ressourcen, die nur staatliche Akteure aufbringen können
3. Die meisten Nutzer sind kein Ziel für solch aufwendige Operationen
4. Moderne Tor-Versionen sind deutlich besser geschützt als die Software, die 2019-2021 verwendet wurde
5. Onion-zu-Onion-Verbindungen sind erheblich sicherer als Clearnet-Zugriffe über Exit Nodes
6. Kontinuierliche Verbesserungen machen das Netzwerk stetig robuster

Die BKA-Operation zeigt nicht, dass Tor "unsicher" ist, sondern dass keine Anonymisierungstechnologie absolute Sicherheit bieten kann – besonders nicht gegen Gegner mit nahezu unbegrenzten Ressourcen. Aber genau darauf war Tor auch nie ausgelegt.

Tor schützt gegen die allermeisten Bedrohungen:

• Kommerzielle Überwachung und Tracking
• Lokale Netzwerk-Überwacher (ISPs, Arbeitgeber)
• Kriminelle, die an euren Daten interessiert sind
• Autoritäre Regime mit begrenzten technischen Fähigkeiten
• Zensur und Geoblocking

Wer als durchschnittlicher Nutzer Tor verwendet, um seine Privatsphäre zu schützen, seine Meinung frei zu äußern oder auf zensierte Inhalte zuzugreifen, kann dies weiterhin mit sehr hoher Sicherheit tun. Wer allerdings plant, eine internationale Kinderpornographie-Plattform zu betreiben und dabei veraltete Software zu verwenden, sollte sich nicht wundern, wenn internationale Strafverfolgungsbehörden erhebliche Ressourcen aufwenden, um ihn zu finden – und das ist auch gut so.

Die entscheidende Botschaft: Lasst euch nicht verunsichern. Tor ist nach wie vor das beste Werkzeug für Online-Anonymität. Aktualisiert eure Software, verwendet Onion Services wo möglich, und denkt daran, dass technische Sicherheit nur ein Teil guter OpSec ist. Der Rest liegt bei euch.

Quellen und weiterführende Links

• Tor Project Statement zur BKA-Operation: https://blog.torproject.org
• Vanguards-lite Spezifikation: https://spec.torproject.org/vanguards-spec
• Tor Metrics (aktuelle Netzwerk-Statistiken): https://metrics.torproject.org
• Chaos Computer Club Stellungnahme
• Akademische Forschung zu Timing-Attacken und Gegenmaßnahmen
• Analyse von The Morpheus: https://www.youtube.com/watch?v=YOJabNSX4V4

The post Die BKA Timing-Attacke auf Tor: Eine technische Einordnung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was Metadaten sind und warum ihr sie kennen solltet

Wenn ihr eine Nachricht verschickt, besteht diese aus zwei Teilen: dem Inhalt („Treffen wir uns um 18 Uhr am Bahnhof?") und den Metadaten – also allen Informationen über diese Nachricht. Metadaten sind „Daten über Daten" und umfassen bei Messengern typischerweise:

• Die Kommunikationspartner: Wer schreibt wem? Welche Telefonnummer oder Benutzer-ID ist Absender, welche Empfänger?
• Die zeitlichen Informationen: Wann wurde die Nachricht gesendet, zugestellt, gelesen? Wie lange dauerte ein Anruf?
• Die technischen Details: Von welchem Gerät, Betriebssystem und Standort wurde kommuniziert? Welche IP-Adresse hatte der Absender?
• Die sozialen Strukturen: Wer ist Mitglied welcher Gruppe? Wie häufig kommunizieren bestimmte Personen miteinander? Wann waren sie zuletzt online?

Der entscheidende Punkt ist: Ende-zu-Ende-Verschlüsselung schützt nur den Inhalt – die Metadaten bleiben in den meisten Fällen für den Messenger-Betreiber vollständig sichtbar. Stellt euch einen Briefumschlag vor: Selbst wenn der Brief darin perfekt versiegelt ist, steht auf dem Umschlag trotzdem Absender, Empfänger und Poststempel. Der Postbote muss diese Informationen sehen, um den Brief zuzustellen. Bei digitaler Kommunikation verhält es sich ähnlich – mit dem Unterschied, dass diese „Umschläge" dauerhaft gespeichert und analysiert werden können.

Das Aggregationsproblem macht einzelne Datenpunkte mächtig

Einzelne Metadaten wirken harmlos. Dass ihr am Dienstag um 14:23 Uhr eine Nachricht an Hans verschickt habt, verrät wenig. Die Macht der Metadaten entfaltet sich erst durch Aggregation – also die Kombination vieler einzelner Datenpunkte über längere Zeiträume.

Eine Stanford-Studie aus dem Jahr 2016 demonstrierte dies eindrucksvoll: Forscher analysierten die Metadaten von 823 Freiwilligen – insgesamt 250.000 Anrufe und 1,2 Millionen SMS. Aus den reinen Verbindungsdaten konnten sie ableiten, welche Teilnehmer vermutlich Herzrhythmusstörungen hatten (regelmäßige Anrufe bei Kardiologen und Herz-Monitoring-Hotlines), wer bestimmte Waffen besaß (Anrufe bei Waffenhändlern und Hersteller-Support) und wer möglicherweise eine Abtreibung plante (Anrufe bei Gynäkologen, gefolgt von Abtreibungskliniken).

Die Electronic Frontier Foundation (EFF) bringt das Problem auf den Punkt mit Beispielen wie: „Sie wissen, dass ihr um 2:24 Uhr morgens bei einer Telefonsex-Hotline angerufen und 18 Minuten gesprochen habt. Aber nicht, worüber." Oder: „Sie wissen, dass ihr die Suizid-Präventions-Hotline von der Golden Gate Bridge aus angerufen habt. Aber das Thema des Gesprächs bleibt geheim."

Warum Metadaten wichtiger sind als Inhalte

Die Aussage, dass Metadaten heute oft interessanter sind als die eigentlichen Kommunikationsinhalte, stammt nicht von Datenschutz-Aktivisten, sondern von den höchsten Ebenen der Geheimdienste selbst.

Die Aussagen von Geheimdienstchefs

Michael Hayden, der sowohl NSA-Direktor (1999-2005) als auch CIA-Direktor (2006-2009) war, sagte bei einer öffentlichen Debatte an der Johns Hopkins University im April 2014: „We kill people based on metadata" – Wir töten Menschen basierend auf Metadaten. Er bestätigte diese Aussage 2016 bei TechCrunch Disrupt: „Metadaten sind unglaublich mächtig. Metadaten sollten keinen Freifahrtschein bekommen."

Stewart Baker, ehemaliger Rechtsberater der NSA, formulierte es noch deutlicher: „Metadaten sagen euch absolut alles über jemandes Leben. Wenn ihr genug Metadaten habt, braucht ihr den Inhalt eigentlich nicht mehr."

Diese Aussagen sind keine Übertreibung: Das NSA-Programm SKYNET wendete maschinelles Lernen auf Mobilfunk-Metadaten von 55 Millionen Menschen in Pakistan an. Der Algorithmus analysierte über 80 verschiedene Verhaltens­indikatoren – Bewegungsmuster, Anrufhäufigkeiten, Reiseverhalten, SIM-Karten-Wechsel, Kontaktnetzwerke – und berechnete „Terrorismuswahrscheinlichkeiten" für potenzielle Drohnenangriffsziele. Zwischen 2.500 und 4.000 Menschen wurden seit 2004 durch Drohnenangriffe in Pakistan getötet, viele davon durch solche „Signatur-Angriffe" basierend auf Verhaltensmustern statt konkreter Beweise.

Warum Metadaten technisch überlegen sind

Für Überwachung haben Metadaten mehrere technische Vorteile gegenüber Inhalten. Die Skalierbarkeit: Während das Abhören und Auswerten von Millionen Telefongesprächen enormen personellen Aufwand erfordert, können Metadaten automatisiert durchsucht und analysiert werden. Die Mustererkennung: Machine-Learning-Algorithmen können aus Metadaten Verhaltensprofile erstellen, soziale Netzwerke kartieren und Anomalien identifizieren. Die Präzision: Metadaten sind eindeutig – ein Zeitstempel oder eine IP-Adresse lässt weniger Interpretationsspielraum als ein mehrdeutiges Gespräch. Die rechtliche Situation: Historisch genießen Metadaten weniger rechtlichen Schutz als Kommunikationsinhalte.

Die Stanford-Studie zeigte außerdem die erschreckende Reichweite: Eine einzige „Seed"-Telefonnummer kann durch Zwei-Hop-Analyse (Kontakte der Kontakte) zur Überwachung von etwa 25.000 Personen führen.

WhatsApp: Verschlüsselung trifft Metadaten-Sammlung

WhatsApp nutzt das Signal-Protokoll für Ende-zu-Ende-Verschlüsselung und bewirbt dies prominent. Die Nachrichteninhalte kann WhatsApp über umwegen trotzdem noch lesen. Bei den Metadaten sieht es anders aus.

Die umfangreiche Datensammlung

Laut WhatsApps eigener Datenschutzrichtlinie sammelt der Dienst: Die komplette Kontaktliste eures Telefons (sofern ihr die Berechtigung erteilt habt), Zeitstempel zu „Zeit, Häufigkeit und Dauer eurer Aktivitäten und Interaktionen", IP-Adressen zur Schätzung des „allgemeinen Standorts (Stadt und Land)" auch ohne aktivierte Standortfunktionen, Gruppenmitgliedschaften inklusive Gruppennamen, Profilbilder und Beschreibungen, Geräteinformationen wie Hardware-Modell, Betriebssystem, Akkustand, Signalstärke, App-Version und Mobilfunkanbieter sowie Nutzungsmuster darüber, wie ihr den Dienst nutzt und mit anderen interagiert.

Diese Daten werden nicht nur für den Betrieb des Dienstes verwendet. WhatsApp teilt Metadaten mit anderen Meta-Unternehmen (Facebook, Instagram). Die geteilten Daten umfassen Telefonnummern, Gerätedaten, Nutzungsmuster und IP-Adressen – verwendet für „zielgerichtete Werbung über Meta-Plattformen hinweg". In der EU beruft sich Meta dabei auf „berechtigte Interessen" nach der DSGVO statt auf explizite Einwilligung – ein Ansatz, der von Datenschützern stark kritisiert wird.

Echtzeit-Metadaten für Behörden

Ein besonders kritischer Aspekt wurde durch FBI-Dokumente bekannt: WhatsApp ist der einzige große Messenger, der bei entsprechenden richterlichen Anordnungen (sogenannten Pen Register) Metadaten in Nahe-Echtzeit alle 15 Minuten an Behörden übermitteln kann. Die Behörden erfahren damit, wer mit wem kommuniziert, wann und wie lange – nur nicht den Inhalt. Wenn die Behörden es wollen, bekommen sie die unverschlüsselten Chatbackups obendrein noch per Anfrage an Google, wahrscheinlich in ähnlicher kurzer Zeit.

Im Mai 2024 enthüllte The Intercept ein internes WhatsApp-Memo, in dem die eigenen Ingenieure warnten, dass „Traffic-Analyse-Schwachstellen es Regierungen ermöglichen, unsere Verschlüsselung zu umgehen". Das Problem: Selbst wenn der Inhalt verschlüsselt ist, können Überwacher durch Analyse von Nachrichtengrößen, Timing und Kommunikationsmustern erhebliche Informationen extrahieren.

Die Architektur als Grundproblem

WhatsApp betreibt eine vollständig zentralisierte Infrastruktur auf Metas globalen Rechenzentren. Der Server-Code ist proprietär und nicht einsehbar. Alle Metadaten laufen über diese zentrale Infrastruktur und können dort aggregiert, analysiert und bei Bedarf an Behörden oder Meta-Partner weitergegeben werden. Die Verschlüsselung der Inhalte ändert daran nichts.

Signal: Der Goldstandard für Metadaten-Schutz

Signal gilt als Referenz für private Kommunikation – und das zu Recht. Anders als die Konkurrenz verfolgt Signal eine radikale Datensparsamkeit, die durch dokumentierte Gerichtsverfahren verifiziert wurde.

Was Signal tatsächlich speichert

Signal speichert nachweisbar nur drei Datenpunkte: Die Telefonnummer (als kryptografischer Hash), das Account-Erstellungsdatum (Unix-Timestamp der Registrierung) und den letzten Verbindungstag (nur das Datum, nicht die Uhrzeit).

Was Signal nicht speichert: IP-Adressen (temporär während Verbindung sichtbar, aber nicht geloggt), Kontaktlisten (werden nur lokal verarbeitet), Gruppenmitgliedschaften (Server kennt weder Gruppen noch deren Mitglieder), Kommunikationspartner (dazu gleich mehr), Nachrichteninhalte (Ende-zu-Ende-verschlüsselt, technisch unzugänglich) und Profilnamen und Avatare (ebenfalls Ende-zu-Ende-verschlüsselt).

Diese Angaben sind nicht nur Marketing-Versprechen. Signal veröffentlicht alle Behördenanfragen auf signal.org/bigbrother. Bei sechs dokumentierten Anfragen zwischen 2016 und 2024 – darunter Grand Jury Subpoenas und Search Warrants – forderten Behörden umfassende Daten: Namen, Adressen, Kommunikationsinhalte, Kontakte, Gruppenmitgliedschaften, Anrufprotokolle. In jedem Fall konnte Signal nur die drei genannten Datenpunkte liefern.

Sealed Sender: Wie Signal die Absender-Identität schützt

Die Innovation, die Signal von allen anderen unterscheidet, ist Sealed Sender (seit Oktober 2018). Diese Technologie funktioniert wie ein Briefumschlag mit verborgenem Absenderfeld.

Der technische Ablauf: Der Sender erhält regelmäßig kurzlebige Sender-Zertifikate vom Server. Bei Nachrichtenversand wird ein zweischichtiges Verschlüsselungsmodell angewandt – der Nachrichteninhalt wird mit dem Signal-Protokoll verschlüsselt, dann wird dieser „innere Umschlag" mit Sender-Zertifikat zusätzlich via X25519-Schlüsselaustausch verschlüsselt. Die Nachricht wird anschließend anonym an den Server übergeben, nur mit dem Delivery-Token des Empfängers. Der Signal-Server kennt dadurch nur das Ziel, nicht den Absender.

Einschränkungen: Eine wissenschaftliche Studie (NDSS 2021, University of Colorado Boulder und Boston University) zeigte, dass bei wiederholter Kommunikation statistische Angriffe theoretisch Sender-Empfänger-Paare korrelieren können. Bei aktivierten Lesebestätigungen könnte Signal bereits nach fünf Nachrichten Nutzer verknüpfen. Dieser Angriff funktioniert sogar gegen Tor/VPN-Nutzer, da er auf Anwendungsebene operiert.

Trotz dieser theoretischen Schwächen ist Sealed Sender ein massiver Fortschritt gegenüber anderen Messengern, bei denen der Server jede Kommunikationsbeziehung vollständig sieht.

Private Contact Discovery mit Hardware-Enklaven

Ein fundamentales Problem beim Kontaktabgleich: Telefonnummern haben einen zu kleinen Keyspace – bei etwa 10 Milliarden möglichen Nummern sind Hashes trivial umkehrbar. Signals Lösung nutzt Intel SGX (Software Guard Extensions) seit September 2017.

SGX erstellt isolierte Speicherbereiche (Secure Enclaves) auf Hardware-Ebene, die selbst für Betriebssystem und Server-Administratoren unzugänglich sind. Der Client baut eine direkte verschlüsselte Verbindung zur Enklave auf und verifiziert via Remote Attestation, dass der veröffentlichte Open-Source-Code tatsächlich läuft. Kontakte werden verschlüsselt an die Enklave gesendet, der Abgleich findet isoliert statt, nur das verschlüsselte Ergebnis wird zurückgesendet.

Da SGX-Schwachstellen bekannt sind (Spectre/Meltdown, Foreshadow, SGAxe, SmashEx), kam 2024 die Antwort mit SVR3 (Secure Value Recovery 3): Das Vertrauen wird auf drei verschiedene Hardware-Technologien bei drei Cloud-Anbietern verteilt – Intel SGX (Microsoft Azure), AWS Nitro (Amazon) und AMD SEV-SNP (Google Cloud). Ein Angreifer müsste alle drei Systeme gleichzeitig kompromittieren.

Das Username-System seit Februar 2024

Signal erfordert weiterhin eine Telefonnummer zur Registrierung – primär um Spam-Accounts zu erschweren. Seit Februar 2024 ermöglicht das Username-System jedoch Kommunikation ohne Telefonnummern-Freigabe.

Usernames dienen ausschließlich der Kontaktaufnahme, nicht der Anzeige im Chat (dort erscheint der Profilname). Sie müssen eindeutig sein und mindestens zwei Ziffern am Ende enthalten (z.B. „axolotl.99"). Es gibt kein durchsuchbares Verzeichnis – der exakte Username muss bekannt sein. Usernames werden nicht im Klartext gespeichert, sondern durch Zero-Knowledge-Proofs geschützt.

Die Telefonnummer ist seit Februar 2024 standardmäßig nicht mehr sichtbar für Personen, die sie nicht bereits gespeichert haben. Bei maximaler Privatsphäre-Einstellung (beide auf „Niemand") ist Kontakt nur über den exakten Username möglich.

Open Source und Server-Transparenz

Signal ist größtenteils Open Source – Client-Apps, Server-Code (Java/Spring Boot), die Kryptografie-Bibliothek libsignal (Rust) und mehr sind öffentlich auf github.com/signalapp verfügbar. Die einzige Ausnahme ist das Anti-Spam-System. Signals Begründung: „Im Gegensatz zu Verschlüsselungsprotokollen, die nachweisbar sicher sein sollen, selbst wenn jeder weiß, wie sie funktionieren, ist Spam-Erkennung eine laufende Aufgabe, für die Transparenz einen großen Nachteil darstellt."

Ein Vertrauensbruch ereignete sich 2020-2021: Vom 22. April 2020 bis 6. April 2021 veröffentlichte Signal keine Server-Updates – elf Monate Stille. Erst nach Community-Kritik erfolgte ein großer „Code Dump". Der Vorfall beschädigte das Vertrauen in die vollständig offene Entwicklung, auch wenn Signal seither wieder regelmäßige Updates veröffentlicht.

Telegram: Trügerische Sicherheit mit fundamentalen Schwächen

Telegram wird oft als sichere Alternative zu WhatsApp wahrgenommen. Bei genauer Betrachtung zeigt sich jedoch, dass Telegram in wichtigen Aspekten weniger privat ist als WhatsApp – und dass sich die Situation seit August 2024 dramatisch verändert hat.

Standard-Chats sind nicht Ende-zu-Ende-verschlüsselt

Der wichtigste Unterschied zu WhatsApp und Signal: Telegrams normale Chats sind nicht Ende-zu-Ende-verschlüsselt. Sie sind lediglich transportverschlüsselt – das heißt, sie sind auf dem Weg zwischen eurem Gerät und Telegrams Servern geschützt, aber Telegram selbst kann alle Nachrichten in Cloud-Chats entschlüsseln und lesen.

Nur die separat aktivierbaren „Geheimen Chats" bieten Ende-zu-Ende-Verschlüsselung. Diese müssen jedoch manuell gestartet werden, sind nur auf einem einzelnen Gerät verfügbar und unterstützen keine Gruppen. In der Praxis nutzen die meisten Menschen die Standard-Cloud-Chats – und wissen oft nicht, dass Telegram deren Inhalt lesen kann.

Die gesammelten Metadaten

Telegram sammelt Telefonnummern (obligatorisch für die Registrierung), IP-Adressen (bis zu 12 Monate gespeichert), Geräteinformationen und die Historie von Benutzernamen-Änderungen. Das Unternehmen betreibt Server in fünf Rechenzentren: zwei in Miami, zwei in Amsterdam und eines in Singapur.

Telegram betont, keine Daten für Werbung zu nutzen und die Verschlüsselungsschlüssel für Cloud-Chats auf mehrere Rechenzentren in verschiedenen Jurisdiktionen zu verteilen. Dies soll es erschweren, Daten durch einzelne Gerichtsurteile herauszugeben.

Die Zäsur nach der Durov-Verhaftung

Im August 2024 wurde Telegram-Gründer Pavel Durov in Frankreich verhaftet. Die Folgen für Telegrams Datenschutz waren dramatisch: Am 23. September 2024 änderte Telegram seine Datenschutzrichtlinie fundamental. Vorher gab Telegram nach eigenen Angaben nur bei „bestätigten Terrorismusermittlungen" Daten heraus und behauptete, „0 Bytes an Nutzernachrichten an Dritte, einschließlich Regierungen" weitergegeben zu haben.

Nach der Änderung gibt Telegram nun bei richterlichen Anordnungen IP-Adressen und Telefonnummern auch für Fälle von Cyberkriminalität, illegalem Warenhandel und Online-Betrug heraus. Die Zahlen sprechen für sich: Im gesamten Jahr 2024 erfüllte Telegram 900 Anfragen der US-Regierung (betraf 2.253 Nutzer), während es vor September nur 14 Anfragen waren (108 Nutzer). Aus Indien kamen 6.992 Anfragen, aus Brasilien 203.

Kritik am MTProto-Protokoll

Telegram verwendet mit MTProto ein selbst entwickeltes Verschlüsselungsprotokoll statt etablierter Standards. Sicherheitsforscher der ETH Zürich und der University of London identifizierten 2021 vier kryptografische Schwächen: Möglichkeiten zur Nachrichtenumordnung, Erkennung verschlüsselter Nachrichtentypen unter bestimmten Bedingungen, theoretische Klartext-Wiederherstellung durch Timing-Seitenkänale und potenzielle Man-in-the-Middle-Angriffe.

Telegram hat diese spezifischen Probleme behoben, doch die grundsätzliche Kritik bleibt: Ein Unternehmen, das eigene Kryptografie entwickelt („roll your own crypto") statt auf auditierte Standards zu setzen, wird von der Security-Community skeptisch betrachtet. Der Server-Code ist zudem nicht Open Source und kann nicht unabhängig überprüft werden.

Threema: Schweizer Datensparsamkeit mit einem großen Vorbehalt

Threema aus der Schweiz verfolgt einen radikal anderen Ansatz: Minimierung aller gesammelten Daten von Anfang an. Der Messenger erfordert keine Telefonnummer und speichert Kontaktlisten ausschließlich auf den Geräten der Nutzer.

Das anonyme ID-System

Statt euch mit einer Telefonnummer zu registrieren, generiert Threema eine zufällige 8-stellige alphanumerische ID direkt auf eurem Gerät. Telefonnummer oder E-Mail-Adresse können optional verknüpft werden – dann werden aber nur gehashte Werte (SHA-256 HMAC) an die Server übertragen. Ihr könnt Threema vollständig anonym nutzen, ohne je persönliche Daten anzugeben.

Minimale Metadaten-Speicherung

Threemas Transparenzbericht listet auf, welche Daten bei behördlichen Anfragen herausgegeben werden können: Das Datum (ohne Uhrzeit) der ID-Erstellung, das Datum (ohne Uhrzeit) des letzten Logins – und falls vom Nutzer verknüpft, den Hash von Telefonnummer oder E-Mail sowie bei kürzlicher Push-Nutzung den Push-Token.

Was Threema nicht herausgeben kann: Nachrichteninhalte (Ende-zu-Ende-verschlüsselt), Kontaktlisten (nur auf Geräten gespeichert), Gruppenmitgliedschaften (nur auf Geräten gespeichert) und IP-Adressen (werden nicht gespeichert). Nachrichten werden sofort nach erfolgreicher Zustellung von den Servern gelöscht.

Die Zahlen zeigen dies: 2024 erhielt Threema 306 behördliche Anfragen und konnte für 852 IDs Daten liefern – aber eben nur die minimalen Informationen, die technisch verfügbar sind.

Die Server-Code-Problematik

Hier liegt die wichtigste Einschränkung bei der Bewertung von Threema: Während die Client-Apps seit 2020 Open Source sind (unter AGPL v3-Lizenz), bleibt der Server-Code proprietär und nicht einsehbar.

Das bedeutet: Ihr müsst Threemas Aussagen über ihr Server-Verhalten glauben. Unabhängige Überprüfung ist nicht möglich. Threema behauptet, minimale Daten zu speichern, keine Logs zu erstellen und Nachrichten sofort zu löschen – aber niemand außerhalb des Unternehmens kann das verifizieren.

Sicherheits-Audits und ETH-Zürich-Kontroverse

Threema verweist auf mehrere externe Audits: Cure53 (2024, Desktop-App), Universität Erlangen-Nürnberg (2023, Ibex-Protokoll-Verifizierung), Cure53 (2020, umfassend), Universität Münster (2019). Allerdings stellten Forscher der ETH Zürich im Januar 2023 fest, dass frühere Audits den kryptografischen Kern der Anwendung nicht untersucht hatten.

Die ETH-Forscher identifizierten sieben Schwachstellen im ursprünglichen Protokoll, darunter Möglichkeiten für Server, die Nachrichtenreihenfolge zu manipulieren oder unter bestimmten Bedingungen Nachrichten zu fälschen. Besonders brisant: Professor Paterson bezeichnete Threemas Reaktion als „extrem irreführend", als das Unternehmen behauptete, das alte Protokoll sei „nicht mehr in Verwendung".

Threema reagierte mit dem neuen Ibex-Protokoll (November 2022), das Perfect Forward Secrecy implementiert. Dieses wurde von deutschen Forschern formal verifiziert – aber eben nur das theoretische Protokoll, nicht die konkrete Implementierung auf den proprietären Servern.

Die Schweizer Jurisdiktion

Die Schweizer Rechtslage bietet einige Vorteile: Das Land unterliegt nicht dem US CLOUD Act, und Threema fällt nach eigenen Angaben nicht unter die Schweizer Vorratsdatenspeicherungspflichten (BÜPF), da die Umsatzschwellen nicht erreicht werden. Ausländische Behörden müssen den offiziellen Rechtshilfeweg über die Schweiz gehen.

Allerdings sind Schweizer Gesetze keine absolute Garantie – bei gültigen Schweizer Gerichtsanordnungen muss auch Threema verfügbare Daten herausgeben. Der Unterschied ist, dass technisch kaum etwas verfügbar ist.

Element und Matrix: Dezentralisierung als zweischneidiges Schwert

Element ist ein Messenger, der auf dem offenen Matrix-Protokoll basiert. Im Gegensatz zu den anderen vorgestellten Diensten ist Matrix föderiert – ähnlich wie E-Mail kann jeder seinen eigenen Server betreiben, und alle Server kommunizieren miteinander.

Die föderierte Architektur erklärt

Bei Matrix registriert ihr euch bei einem „Homeserver" – entweder dem öffentlichen matrix.org (betrieben von Element) oder einem selbst gehosteten Server. Wenn ihr mit jemandem auf einem anderen Server kommuniziert, werden die Nachrichten zwischen den Servern repliziert.

Dies hat fundamentale Auswirkungen auf Metadaten: In einem Gruppenchat mit Teilnehmern von fünf verschiedenen Servern speichern alle fünf Server die Metadaten – wer Mitglied ist, wann Nachrichten geschickt wurden, wer wann beigetreten oder gegangen ist. Wenn ein neuer Server einem Raum beitritt, erhält er eine vollständige Kopie aller historischen Metadaten.

Was für Homeserver-Betreiber sichtbar ist

Homeserver-Betreiber können sehen: Benutzer-IDs und Anzeigenamen, Raummitgliedschaften (wer ist in welchen Räumen), Geräte-IDs und -informationen, Zeitstempel aller Nachrichten, wer mit wem wann kommuniziert und die IP-Adressen ihrer eigenen Nutzer.

Selbst in Ende-zu-Ende-verschlüsselten Räumen bleiben Mitgliedschaften im Klartext sichtbar. Beitritts-, Austritts- und Verbannungsereignisse müssen für die Protokollintegrität dauerhaft gespeichert werden.

Element spezifisch

Die Element-App nutzt standardmäßig den matrix.org-Server, der etwa 35% aller aktiven Matrix-Nutzer repräsentiert – ein gewisses Zentralisierungsproblem für ein dezentrales Protokoll. Element als Unternehmen sammelt bei Nutzung ihrer Server: Account-Authentifikatoren, E-Mail-Adressen (falls angegeben), IP-Adressen und Geräte-Agenten (bei Opt-in für Analytics) sowie Push-Token für Benachrichtigungen.

Der große Unterschied zu WhatsApp, Signal oder Telegram: Keine Telefonnummer ist erforderlich, und ihr könnt euren eigenen Server betreiben mit vollständiger Kontrolle über die Datenaufbewahrung.

Ein wichtiger Aspekt bei der Bewertung von Matrix: Die meisten Matrix-Server (Synapse-Instanzen) werden von datenschutzfreundlichen Betreibern gehostet – Universitäten, Privacy-Organisationen, Tech-Communities oder Privatpersonen. Diese Betreiber haben im Gegensatz zu Meta oder Google kein Geschäftsmodell, das auf Datenauswertung basiert. Während WhatsApp Metadaten systematisch für Werbezwecke analysiert, haben die meisten Matrix-Serverbetreiber weder das Interesse noch die technische Infrastruktur für solche Analysen. Die technische Möglichkeit zum Metadaten-Zugriff besteht zwar, aber die wirtschaftlichen Anreize zur Auswertung fehlen vollständig.

Dezentralisierung: Vor- und Nachteile für Metadaten

Die Vorteile: Kein einzelner Angriffspunkt, keine zentrale Überwachungsmöglichkeit, Self-Hosting ermöglicht volle Datensouveränität, geschlossene Föderationen möglich (wie beim Bundeswehr-Messenger BwMessenger oder dem französischen Behörden-Messenger Tchap).

Die Nachteile: Metadaten verteilen sich auf alle teilnehmenden Server – ihr müsst nicht nur eurem eigenen Server vertrauen, sondern auch allen Servern in Räumen, denen ihr beitretet. Das Löschen von Daten ist nur eine Empfehlung – andere Server in der Föderation können Daten behalten. Das DSGVO-Recht auf Löschung wird vom Protokoll unterstützt, kann aber für föderierte Server außerhalb der Kontrolle von Element nicht garantiert werden.

Aktuelle Entwicklungen 2024/2025

Matrix 2.0, veröffentlicht im Oktober 2024, brachte „Invisible Encryption" – Ende-zu-Ende-Verschlüsselung so nahtlos wie bei Signal. Die Integration des MLS-Protokolls (Messaging Layer Security, RFC 9420), dem IETF-Standard für Gruppenverschlüsselung, ist in Arbeit. MLS könnte Gruppenmitgliedschaften kryptografisch verschleiern – der Server würde nur einen verschlüsselten Blob sehen.

Experimentell wird an P2P-Matrix gearbeitet, das Server-seitige Metadaten vollständig eliminieren würde, sowie an „Mixnets of blinded store & forward servers", um zu verschleiern, wer mit wem kommuniziert.

Architektur-Unterschiede im Überblick

Die verschiedenen Ansätze zur Server-Architektur haben fundamentale Auswirkungen darauf, wer Zugriff auf Metadaten hat.

Zentralisierte Architektur (WhatsApp, Signal, Telegram, Threema): Ein einzelnes Unternehmen betreibt alle Server. Alle Metadaten fließen durch diese zentrale Infrastruktur. Dies ermöglicht effiziente Zustellung und einfache Skalierung, schafft aber einen „Single Point of Compromise" – eine behördliche Anfrage an dieses eine Unternehmen reicht aus, um Zugriff auf Metadaten zu erhalten.

Bei WhatsApp und Telegram bedeutet dies umfangreichen Metadaten-Zugriff. Bei Signal und Threema soll es durch technische Datensparsamkeit bedeuten, dass wenig Verwertbares vorhanden ist. Signal kann dies durch dokumentierte Gerichtsverfahren belegen, bei Threema muss man dem Unternehmen glauben.

Föderierte Architektur (Matrix/Element): Metadaten verteilen sich auf viele Server. Es gibt keinen zentralen Honeypot, aber potenziell mehr Stellen, an denen Metadaten abgegriffen werden können. Der Vorteil: Wer seinen eigenen Server betreibt, behält die volle Kontrolle über seine Daten – zumindest soweit es die eigene Seite der Kommunikation betrifft.

Peer-to-Peer-Architektur (Briar, nicht Teil des Vergleichs): Gar keine zentralen Server. Nachrichten werden direkt zwischen Geräten ausgetauscht, optional über Tor für zusätzliche Anonymität. Der Nachteil: Beide Gesprächspartner müssen gleichzeitig online sein.

Technische Ansätze zum Metadaten-Schutz

Die vollständige Eliminierung von Metadaten ist technisch extrem schwierig – schließlich muss ein System irgendwie wissen, wohin eine Nachricht zugestellt werden soll. Verschiedene Ansätze versuchen, dieses Problem zu minimieren.

Sealed Sender bei Signal

Signals Sealed Sender (siehe ausführliche Erklärung im Signal-Abschnitt) ist der aktuell fortschrittlichste Ansatz in einem Mainstream-Messenger: Der Absender wird vom äußeren Nachrichtenumschlag entfernt und erst innerhalb der verschlüsselten Nachricht übermittelt. Signals Server sehen so nur, dass jemand eine Nachricht an Empfänger B schickt – aber nicht, dass es Absender A war.

Die Einschränkungen: IP-Adressen bleiben sichtbar (können mit VPN/Tor maskiert werden). Bei bidirektionaler Kommunikation ist Korrelation durch Timing-Analyse weiterhin möglich. Forscher haben gezeigt, dass Zustellbestätigungen, Timing-Muster und Nachrichten-Logs zur Deanonymisierung genutzt werden können.

Private Contact Discovery

Das traditionelle Problem: Um herauszufinden, welche eurer Kontakte einen Messenger nutzen, muss eure Kontaktliste hochgeladen werden – was euer soziales Netzwerk offenlegt.

WhatsApp lädt die gesamte Kontaktliste regelmäßig hoch. Signal nutzt Intel SGX (sichere Enklaven) für Abfragen, bei denen selbst der Server die Anfragen nicht sehen kann – wobei SGX bekannte Schwachstellen hat, die durch SVR3 mit Multi-Cloud-Strategie adressiert werden. Threema macht den Adressbuch-Abgleich optional und löscht die Daten sofort nach der Synchronisation.

Onion Routing und Mix-Netzwerke

Onion Routing (bekannt von Tor) wickelt Nachrichten in mehrere Verschlüsselungsschichten. Jeder Relay-Server kennt nur seinen Vorgänger und Nachfolger, nicht die ursprüngliche Quelle oder das endgültige Ziel. Der Messenger Briar routet allen Datenverkehr über Tor, der Messenger Session nutzt ein eigenes dezentrales Onion-Netzwerk.

Mix-Netzwerke gehen noch weiter: Nachrichten werden verzögert und mit anderen gemischt, bevor sie weitergeleitet werden. Dies erschwert Timing-Korrelationen erheblich, führt aber zu Latenzen von Minuten statt Sekunden.

Die fundamentalen Grenzen

Trotz aller Techniken bleibt Metadaten-Schutz ein ungelöstes Problem. Euer Internet-Provider sieht immer, dass ihr euch mit Messenger-Servern verbindet. Selbst mit Verzögerungen können sophistizierte Angreifer durch statistische Analyse Kommunikationspaare identifizieren. Starke Anonymität erfordert hohe Latenz, Bandbreiten-Overhead und Komplexität – alles Faktoren, die der Benutzerfreundlichkeit entgegenstehen.

Die Messenger aus unserem Vergleich versuchen unterschiedliche Balancen: WhatsApp opfert Metadaten-Schutz vollständig für Funktionalität und Geschäftsmodell. Telegram macht ähnliche Trade-offs, jetzt noch verstärkt nach der Durov-Verhaftung. Signal hat mit Sealed Sender und Private Contact Discovery die fortschrittlichsten Mainstream-Lösungen implementiert. Threema minimiert gespeicherte Metadaten durch technische Architektur, erfordert aber Vertrauen in nicht-überprüfbare Aussagen. Matrix verschiebt das Problem auf die Föderations-Ebene, wo Self-Hosting echte Kontrolle ermöglicht – auf Kosten der Komplexität.

Reale Fälle von Metadaten-Überwachung

Die theoretischen Risiken von Metadaten sind durch zahlreiche dokumentierte Fälle belegt.

Der BTK-Killer und die Floppy-Disk-Metadaten

Dennis Rader, der „BTK-Killer", terrorisierte Wichita über 30 Jahre und tötete 10 Menschen. Gefangen wurde er 2005 durch Metadaten: Eine Floppy Disk, die er an die Polizei schickte, enthielt in den Dokumenteigenschaften die Worte „Christ Lutheran Church" und „Dennis" – was ihn direkt als Gemeinde-Präsident identifizierte.

Europäische Vorratsdatenspeicherung

Nach den Terroranschlägen in Madrid (2004) und London (2005) verpflichtete die EU-Richtlinie 2006/24/EG alle Mitgliedstaaten zur Vorratsdatenspeicherung. Telekommunikationsanbieter mussten Verkehrs- und Standortdaten aller Bürger zwischen sechs Monaten und zwei Jahren speichern – ohne konkreten Verdacht.

Deutschland setzte die Richtlinie 2008 um, doch bereits 2010 erklärte das Bundesverfassungsgericht die Regelung für verfassungswidrig. Österreichs Verfassungsgerichtshof folgte 2014. Schließlich kippte der Europäische Gerichtshof 2014 die gesamte EU-Richtlinie als Verstoß gegen die Grundrechtecharta.

Ein oft zitiertes Erfolgsbeispiel der Vorratsdatenspeicherung war die Operation "Himmel" 2007: Ermittler identifizierten durch gespeicherte IP-Adressen über 70 deutsche Provider und damit 1.200 Tatverdächtige im Zusammenhang mit Kinderpornographie. Kritiker weisen jedoch darauf hin, dass auch ohne Vorratsdatenspeicherung 71% aller Internetdelikte aufgeklärt wurden – mehr als außerhalb des Internets begangene Straftaten (55%). Eine Analyse des wissenschaftlichen Dienstes des Bundestags kam zu dem Schluss, dass in der EU keine Hinweise existieren, dass die verdachtsunabhängige Protokollierung von Nutzerspuren den Ermittlungsbehörden nachweislich hilft.

Journalistische Quellenschutz-Gefährdung

Im Februar 2013 beschlagnahmte das US-Justizministerium heimlich Telefonaufzeichnungen von Reportern und Redakteuren der Associated Press – 20 separate Telefonleitungen über zwei Monate, darunter Büroleitungen in Washington, New York und Hartford sowie Privat- und Handynummern einzelner Journalisten. Ziel war die Identifikation von Quellen für einen Artikel über eine CIA-Operation.

AP-Chef Gary Pruitt beschrieb die Auswirkungen: „Diese Aufzeichnungen offenbaren potenziell Kommunikation mit vertraulichen Quellen über alle Nachrichtenbeschaffungsaktivitäten der AP während eines Zwei-Monats-Zeitraums, liefern eine Roadmap zu APs Nachrichtenbeschaffungsoperationen... Einige unserer langjährigen vertrauenswürdigen Quellen sind nervös und ängstlich geworden, mit uns zu sprechen."

NSA-Massenüberwachung: PRISM und XKeyscore

Im Juni 2013 enthüllte Edward Snowden, ehemaliger NSA-Mitarbeiter, das Ausmaß der amerikanischen Metadaten-Überwachung. Das PRISM-Programm ermöglichte der NSA direkten Zugriff auf die Server von Microsoft, Google, Facebook, Apple, Yahoo, YouTube und weiteren Tech-Giganten. Im März 2013 sammelte die NSA allein 97 Milliarden Datensätze aus globalen Computernetzwerken.

Besonders aufschlussreich war die Enthüllung von XKeyscore – ein System, das NSA-Analysten erlaubte, ohne vorherige Autorisierung durch E-Mail-Adressen, Telefonnummern, IP-Adressen oder Suchbegriffe sämtliche Metadaten zu durchsuchen. Snowden beschrieb: „Ich könnte von meinem Schreibtisch aus jeden ausspionieren – Sie, Ihren Buchhalter, einen Bundesrichter oder sogar den Präsidenten, wenn ich eine private E-Mail-Adresse hätte."

Die Zusammenarbeit war international: Deutschlands BND übermittelte täglich massive Mengen an Metadaten über die Bad Aibling Station an die NSA. Laut einer vom Guardian veröffentlichten Karte gehörte Deutschland im März 2013 zu den am stärksten überwachten Ländern – auf einem Level mit Saudi-Arabien, dem Irak und China. Zwischen Dezember 2012 und Januar 2013 sammelte die NSA allein in Spanien Metadaten von 60 Millionen Telefonaten.

Herzschrittmacher-Metadaten vor Gericht

Im Jahr 2016 wurde Ross Compton verdächtigt, Versicherungsbetrug und Brandstiftung begangen zu haben. Die Metadaten seines Herzschrittmachers – Herzfrequenz, Schrittmacheraktivität, Rhythmen – bewiesen, dass er unmöglich so aus dem Feuer geflohen sein konnte, wie er behauptete. Es war der erste Fall, in dem medizinische Geräte-Metadaten als Schlüsselbeweis dienten.

Swisscom-Bewegungsdaten während Corona

Im März 2020, während des Corona-Lockdowns, stellte die Swisscom dem Bundesamt für Gesundheit (BAG) Standortdaten aus ihrem Mobilfunknetz zur Verfügung. Das System erfasste Gebiete mit mindestens 20 SIM-Karten auf einer Fläche von 100×100 Metern und übermittelte diese Daten mit 24 Stunden Verzögerung an die Behörden. Offizielles Ziel war die Überprüfung, ob sich die Bevölkerung an das Verbot von Menschenansammlungen hält. Die ersten Auswertungen wurden von Gesundheitsminister Alain Berset öffentlich präsentiert: Die Daten zeigten, dass „seit dem Versammlungsverbot deutlich weniger Menschen unterwegs sind" und die Bevölkerung sich „diszipliniert verhält". Obwohl die Swisscom versicherte, die Daten seien „vollständig anonymisiert und aggregiert", demonstrierte der Fall die technische Machbarkeit flächendeckender Bewegungsüberwachung durch Telekomanbieter – eine Infrastruktur, die bei Bedarf auch für andere Zwecke genutzt werden könnte.

Praktische Implikationen für eure Messenger-Wahl

Nach dieser umfassenden Analyse lassen sich folgende Einordnungen treffen:

Signal ist der Goldstandard für Metadaten-Schutz unter Mainstream-Messengern. Sealed Sender, Private Contact Discovery mit Hardware-Enklaven, dokumentiert minimale Datenspeicherung (verifiziert durch Gerichtsverfahren), größtenteils Open Source (Client und Server) und Username-System seit Februar 2024. Die Einschränkung: Telefonnummer weiterhin für Registrierung erforderlich, aber muss nicht mehr geteilt werden. Signal ist die klare Empfehlung für alle, die Metadaten-Schutz ernst nehmen.

WhatsApp bietet "Inhaltsverschlüsselung" heisst ihr Zeit geschützt vor Häckern oder neugierigen Dritten geschützt, nicht jedoch vor WhatsApp selber, zudem sammelt WhatsApp umfangreich Metadaten und teilt diese mit Meta für Werbezwecke. Die Echtzeit-Metadaten-Übermittlung an Behörden ist einzigartig unter den großen Messengern. Für Menschen in der EU oder anderen Regionen mit starken Datenschutzgesetzen mag dies durch regulatorische Beschränkungen abgemildert werden – aber die technische Architektur ermöglicht umfassende Überwachung.

Telegram bietet weniger Schutz als oft angenommen: Keine Ende-zu-Ende-Verschlüsselung als Standard, umfangreiche Server-seitige Datenspeicherung und seit September 2024 wesentlich kooperativere Zusammenarbeit mit Behörden. Die Verteilung auf mehrere Jurisdiktionen bietet einen gewissen Schutz, aber das proprietäre Protokoll und die geschlossene Server-Software erfordern Vertrauen in das Unternehmen.

Threema verfolgt einen konsequenten Datensparsamkeits-Ansatz mit anonymer Registrierung (keine Telefonnummer erforderlich) und minimaler Metadaten-Speicherung. Der kritische Vorbehalt bleibt der proprietäre Server-Code – ihr müsst Threemas Aussagen über ihr Verhalten glauben, ohne sie verifizieren zu können. Die Schweizer Jurisdiktion bietet zusätzlichen rechtlichen Schutz. Threema ist eine gute Wahl für alle, die keine Telefonnummer preisgeben wollen und bereit sind, dem Schweizer Unternehmen zu vertrauen.

Element/Matrix ist die einzige wirklich auditierbare Option: Server und Client sind Open Source. Self-Hosting gibt euch vollständige Kontrolle. Der Nachteil ist die Komplexität föderierter Metadaten-Verteilung – in Räumen mit vielen externen Teilnehmern verteilen sich eure Metadaten entsprechend weit. Matrix ist ideal für technisch versierte Nutzer, Organisationen mit eigener IT-Infrastruktur oder alle, die vollständige Kontrolle über ihre Daten wollen. Wer Lust hat, kann sich unserem Schweizer Matrix Server anschliessen, wir werten keine Daten aus, und verkaufen diese auch nicht weiter.

Fazit: Die Grenzen der Ende-zu-Ende-Verschlüsselung

Die Verschlüsselung von Nachrichteninhalten war ein wichtiger Fortschritt für die digitale Privatsphäre. Aber sie löst nur die Hälfte des Problems. Metadaten – wer mit wem kommuniziert, wann, wie oft, von wo – können genauso viel oder mehr über Menschen verraten wie die Inhalte selbst.

Die verschiedenen Messenger gehen mit diesem Problem unterschiedlich um. WhatsApp und Telegram haben sich für Geschäftsmodelle entschieden, die umfangreiche Metadaten-Sammlung entweder aktiv nutzen (WhatsApp/Meta) oder zumindest ermöglichen (Telegram). Signal hat technische Innovationen wie Sealed Sender entwickelt und durch dokumentierte Gerichtsverfahren bewiesen, dass seine Datensparsamkeit echt ist – nicht nur Marketing. Threema hat technische Datensparsamkeit zum Kernprinzip gemacht, erfordert aber Vertrauen in nicht-überprüfbare Unternehmensaussagen. Matrix/Element bietet als einziges vollständig auditierbares System echte Transparenz, kommt aber mit der Komplexität föderierter Architekturen.

Die Aussage „Metadaten sind interessanter als Inhalte" ist keine Übertreibung von Datenschutz-Aktivisten – sie stammt von denjenigen, die diese Daten nutzen. Michael Haydens Worte von 2014 sind aktueller denn je: In einer Welt, in der algorithmische Systeme Verhaltensmuster analysieren, Beziehungsnetzwerke kartieren und Vorhersagen treffen können, sind die Daten über unsere Kommunikation oft aussagekräftiger als die Kommunikation selbst.

Für eure Messenger-Wahl bedeutet das: Achtet nicht nur auf das Verschlüsselungs-Symbol. Achtet darauf, welche Metadaten gesammelt werden, wie lange sie gespeichert werden, wer Zugriff hat und ob diese Aussagen überprüfbar sind. Signal zeigt, dass es möglich ist, einen benutzerfreundlichen Messenger mit echtem Metadaten-Schutz zu bauen – dokumentiert durch Gerichtsverfahren, nicht nur durch Marketing-Versprechen. Nur so könnt ihr eine informierte Entscheidung treffen.

The post Metadaten bei Messengern: Was Nachrichten über euch verraten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Anfang: UEFI sollte doch funktionieren

Mein Laptop hat UEFI-BIOS, Secure Boot war deaktiviert, eigentlich beste Voraussetzungen. Also Linux Mint 22.2 installiert – automatische Installation, sollte ja alles von alleine klappen. Neustart: No bootable device. Okay, vielleicht war die automatische Installation das Problem.

Versuch Nummer 2: Manuelle Installation

Also nochmal, diesmal manuell:

• EFI-Partition angelegt (512MB, FAT32)
• Auf /boot/efi gemountet
• Rest normal partitioniert
• Installation durchgeführt

Alles lief fehlerfrei durch. Neustart: No bootable device. Wieder.

Im BIOS? Kein Ubuntu-Eintrag, keine Linux-Option – nur die Festplatte wird angezeigt. Aber die bootet halt nicht.

Die Fehlersuche beginnt

Nach einigem Troubleshooting stellte sich heraus: Der Bootloader war technisch korrekt installiert, die EFI-Partition hatte alle richtigen Flags (boot, esp), GRUB war da wo er sein sollte (/EFI/ubuntu/grubx64.efi). Aber das BIOS ignorierte es komplett.

Der Fallback-Versuch

Viele ältere UEFI-BIOS suchen nur nach einem Standard-Fallback-Pfad: /EFI/BOOT/BOOTX64.EFI. Die Idee war, GRUB dorthin zu kopieren:

sudo mount /dev/sdb1 /mnt/efi
sudo mkdir -p /mnt/efi/EFI/BOOT
sudo cp /mnt/efi/EFI/ubuntu/grubx64.efi /mnt/efi/EFI/BOOT/BOOTX64.EFI

Sollte eigentlich funktionieren – viele Leute berichten, dass dieser Trick bei buggy UEFI-Implementierungen hilft. Bei mir? No bootable device. Immer noch.

An diesem Punkt war ich ehrlich gesagt ziemlich genervt.

Legacy-Modus: Der Ausweg aus der UEFI-Blödsinn

Nach mehreren gescheiterten UEFI-Versuchen blieb nur noch eine Option: Legacy-Modus (CSM). Klingt nach Rückschritt, aber bei so alten Laptops oft die zuverlässigere Lösung.

Aber auch Legacy scheitert erstmal beim automatischem Installer

Im BIOS Legacy aktiviert, automatische Installation gestartet. Sollte jetzt doch klappen, oder? Fehlanzeige: "Schwerwiegender Fehler: Bootloader konnte nicht auf /dev/sdb installiert werden" Manuell liest sich der Bootloader auch nicht installieren. Was zur Hölle??

Der nächste Anlauf: Manuelle Installation

Gut, nächster Versuch: Manuelle Partitionierung, keine EFI-Partition, kein Schnickschnack. Einfach Root-Partition, Swap, Bootloader auf /dev/sdb – sollte doch so passen.

Aber nein, jetzt kam eine neue Meldung: "This installation requires separate partition for bootloader code... should be marked as reserved BIOS boot area..."

Nach 7-8 Installationsversuchen war ich ehrlich gesagt kurz davor, dem alten Ding seine wohlverdiente Ruhe zu gönnen. Leider war es nicht mein Laptop, also musste er weiterleben.

Der Haken mit GPT

Nach weiterer Problemsuche kam endlich die Erleuchtung: Die Festplatte hatte noch die GPT-Partitionstabelle von den UEFI-Versuchen. Legacy-BIOS braucht aber MBR (msdos).

Der Grund für all die gescheiterten Versuche: Der Mint-Installer ändert die Partitionstabelle nicht automatisch von GPT auf MBR um. Er versucht einfach, mit der vorhandenen GPT-Tabelle weiterzumachen, was im Legacy-Modus aber nicht richtig funktioniert.

Die Lösung: MBR-Partitionstabelle

sudo parted /dev/sdb mklabel msdos
sudo partprobe /dev/sdb

Damit wurde die Partitionstabelle auf MBR umgestellt. Im Installer kam zwar noch eine verwirrende Warnung wegen fehlender EFI-Partition (obwohl ich eindeutig im Legacy-Modus war – nervig!), aber die ließ sich wegklicken.

Dann normal partitioniert:

• Swap-Partition
• Root-Partition (/)
• Bootloader auf /dev/sdb (die ganze Platte, nicht eine Partition!)

Installation durchgeführt, Neustart und... ES BOOTETE ENDLICH! 🎉

Was lernen wir daraus

Bei älteren Laptops (ca. 10 Jahre und älter) kann UEFI problematisch sein:

1. UEFI-Implementierungen sind oft buggy – besonders bei Budget-Laptops wie Acer, Asus, Lenovo Ideapad etc.
2. Das BIOS schreibt Boot-Einträge nicht richtig ins NVRAM oder ignoriert sie komplett
3. Legacy-Modus ist bei solchen Systemen oft zuverlässiger, auch wenn es nach Rückschritt klingt

Wenn ihr auf "No bootable device" nach Linux-Installation stoßt:

1. Prüft im BIOS ob Boot-Einträge für Linux existieren
2. Wenn UEFI nicht will: Probiert den Fallback-Pfad (/EFI/BOOT/BOOTX64.EFI)
3. Wenn das auch nicht hilft: Legacy-Modus mit MBR-Partitionstabelle ist euer Freund
4. Wichtig bei Legacy: Die Festplatte muss zwingend MBR (msdos) statt GPT haben!

Fazit

Nach mehreren UEFI-Versuchen, verschiedenen Fixes, 2 Stunden herumprobieren und einiger Frustration läuft Linux Mint jetzt einwandfrei im Legacy-Modus. Ist das technisch "rückständig"? Vielleicht. Funktioniert es stabil und zuverlässig? Absolut.

Bei älteren Laptops ist Legacy oft der pragmatischere Weg. Spart euch die Kopfschmerzen mit buggy UEFI-Implementierungen und geht direkt zu dem, was funktioniert.

The post Linux und ältere UEFI Laptops: no bootable device appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Es gibt einen besseren Weg: Hardware-Keys wie der YubiKey. Klingt kompliziert? Ist es nicht. Im Gegenteil – es ist sogar bequemer als das Code-Getippe. Aber Vorsicht: Nextcloud macht es euch nicht ganz einfach, und ohne das richtige Setup verschenkt ihr das Sicherheitsplus komplett.

Das Problem mit den 6-stelligen Codes

TOTP-Apps wie Google Authenticator generieren Einmalpasswörter, die 30 Sekunden gültig sind. Solide Technologie, aber mit einer fatalen Schwäche: Diese Codes können abgefangen werden.

Stellt euch vor, ihr landet auf einer täuschend echten Phishing-Seite eurer Nextcloud. Passwort rein, TOTP-Code hinterher – und schon hat der Angreifer beide Informationen. In den entscheidenden 30 Sekunden kann er sich damit auf der echten Nextcloud anmelden. Game over.

Ein Hardware-Key wie der YubiKey macht diesen Angriff unmöglich. Warum? Weil nie ein Code übertragen wird, den man abfangen könnte.

Diese drei technische Vorteile machen den Unterschied:

Phishing-Resistenz: Der private Schlüssel verlässt den Key nie. Die Signatur ist an die Domain gebunden. Fake-Seiten haben keine Chance.

Kein Shared Secret: Bei TOTP teilen sich Server und Client ein Geheimnis. Wird der Server kompromittiert, kann der Angreifer beliebige Codes generieren. Bei U2F speichert der Server nur den öffentlichen Schlüssel – nutzlos für Angreifer.

Replay-Schutz: Jede U2F-Signatur enthält einen Zähler. Abgefangene Signaturen lassen sich nicht wiederverwenden.

Wie U2F wirklich funktioniert

U2F (Universal 2nd Factor) basiert auf Public-Key-Kryptographie. Der YubiKey enthält einen privaten Schlüssel, der das Gerät niemals verlässt. Bei der Anmeldung fordert Nextcloud eine signierte Bestätigung an – und der Key prüft vorher, ob die Domain stimmt.

Phishing-Seite mit falscher Domain? Der Key verweigert die Signatur. Keine Chance für den Angreifer, egal wie gut die Fake-Seite aussieht.

Hardware-Auswahl: Was funktioniert

Die Klassiker sind YubiKeys von Yubico, aber auch Nitrokeys funktionieren. Wichtig:

• USB-C oder USB-A? Richtet sich nach euren Geräten. Manche Keys haben beide Anschlüsse.
• NFC-fähig? Praktisch für Smartphones. Ein YubiKey 5 NFC kostet um die 79 CHF und deckt beide Szenarien ab.
• Robustheit zählt: Der Key hängt am Schlüsselbund. Billigware hält das nicht lange durch.

Kauft am besten zwei Keys und registriert beide. Einer geht verloren oder kaputt? Der zweite ist euer Backup.

Das Beste: Ihr steckt den Key rein (oder haltet ihn ans Smartphone), drückt den Knopf – fertig. Kein Code-Getippe, kein Stress mit abgelaufenen Zeitfenstern. Was einfach ist, wird auch konsequent genutzt.

Nextclouds WebAuthn-Falle (und wie ihr sie umgeht)

Hier wird es tricky, und das ist der Punkt, an dem viele scheitern: Nextcloud hat WebAuthn zweimal eingebaut, und die beiden Varianten machen völlig verschiedene Dinge.

Die integrierte WebAuthn-Funktion findet ihr unter Einstellungen → Sicherheit → "Passwortlos". Das klingt gut, ist aber keine echte Zwei-Faktor-Authentisierung. Hier ersetzt der YubiKey nur das Passwort. Das Problem: Ihr könnt euch weiterhin mit eurem normalen Passwort anmelden. Wenn das Passwort gephisht wird, seid ihr nicht geschützt. Faktisch habt ihr dann nur einen Faktor – entweder Passwort oder YubiKey.

Was ihr wirklich braucht: Die separate App "Two-Factor WebAuthn" (auch "twofactor_webauthn" genannt). Die findet ihr nicht in den Nextcloud-Einstellungen, sondern müsst sie als App installieren:

1. Apps → Nach "webauthn" suchen
2. "Two-Factor WebAuthn" installieren (oder direkt von GitHub: https://github.com/nextcloud/twofactor_webauthn)

Dann in den persönlichen Einstellungen unter Einstellungen → Sicherheit den YubiKey als 2FA registrieren in der 2FA Sektion aktivieren, nicht unten in der Sektion "Authentifizierung ohne Passwort"

Steckt euren Yubikey an euer Gerät, Klickt auf Sicherhschlüssel hinzufügen, danach öffnet sich ein Fenster in dem ihr den PIN eures Yubikeys eingebt. Danach werdet ihr aufgefordert das Gerät zu berühren. Danach passiert erstmal nichts, und man denkt, es hat nicht geklappt, aber in der Nextcloud entsteht ein kleines Feld, in dem ihr dem Sicherheitschlüssel einen Namen geben müsst. Gebt ihr Yubikey oder ähnlich ein, und klickt auf dann auf Hinzufügen neben dem Feld.

Jetzt habt ihr echte Zwei-Faktor-Auth: Passwort + YubiKey. Beide werden abgefragt, keiner allein reicht.

Loggt ihr euch nun aus, und wieder ein, müsst ihr euren Yubikey berühren, ansonsten gehts nicht weiter.

Backup-Codes: Euer Rettungsanker

Registriert am besten zwei YubiKeys – aber selbst dann kann es passieren, dass beide gerade nicht verfügbar sind. Urlaub ohne Key, defekte Hardware, oder schlicht verloren. Für genau diese Fälle gibt es Backup-Codes.

So erstellt ihr sie:

1. Nextcloud → Einstellungen → Sicherheit
2. Scrollt zu "Backup-Codes generieren"
3. Codes werden einmalig angezeigt – falls ihr wegklickt, könnt ihr den erstellten Backup-Code nicht erneut anzeigen lassen.

Wichtig: Druckt die Codes aus und verwahrt sie an einem sicheren Ort. Nicht digital auf dem gleichen Gerät speichern, auf dem ihr die Nextcloud nutzt. Jeder Code funktioniert einmalig – habt ihr alle aufgebraucht, generiert neue.

Diese Codes sind eure letzte Verteidigungslinie. Ohne sie und ohne YubiKey müsste ein Administrator eure 2FA manuell zurücksetzen – zeitaufwendig und nervig für alle Beteiligten.

Der Rollout: Sessions invalidieren nicht vergessen

Ein häufiger Fehler beim Aktivieren von 2FA: Alte Sessions bleiben aktiv. Wenn ihr 2FA erzwingt, aber eure Nextcloud-Apps auf dem Smartphone noch mit alten Login-Daten laufen, umgeht ihr eure eigene Sicherheit.

Nach der 2FA-Aktivierung:

1. Geht zu Einstellungen → Sicherheit → "Geräte & Sitzungen"
2. Klickt auf das oder die Geräte, das ihr trennen wollt, z.B. Android oder iPhone
3. Meldet euch überall neu an.

Moderne Nextcloud-Android-Apps nutzen übrigens OAuth2 über den System-Browser. Das heißt: NFC funktioniert! Login über Browser → YubiKey mit NFC ans Smartphone halten → fertig. Kein mühsames App-Passwort nötig.

App-Passwörter: Wann ihr sie wirklich braucht

Moderne Android-Apps wie Etar (Kalender) oder die Kontakte-App können über DAVx5 synchronisieren, welches OAuth2 unterstützt. Hier funktioniert der YubiKey-Login problemlos – kein App-Passwort nötig.

Desktop-Clients wie Thunderbird (Kalender/Kontakte) oder die Mint Kalender-App unterstützen dagegen kein OAuth2. Hier müsst ihr App-Passwörter verwenden:

1. Nextcloud → Einstellungen → Sicherheit → "Geräte & Sitzungen"
2. Scrollt zu "App-Passwörter erstellen"
3. Name eingeben (z.B. "Thunderbird Desktop")
4. Generiertes Passwort kopieren und in Thunderbird oder etc. neu anmelden und verwenden

Tipp: Erstellt ein App-Passwort pro Gerät, nicht pro App. Beispiel: "Desktop-PC", "Laptop", "Pixel Tablet". So könnt ihr bei Verlust einzelne Geräte sperren, ohne alle anderen neu konfigurieren zu müssen.

Die Grenzen: Wo es hakt und Alternativen zum Yubikey mit Bitwarden Passwortmanager

Keine Technologie ist perfekt. U2F braucht Hardware, und die kann man vergessen. Der YubiKey muss zum täglichen Begleiter werden wie der Büroschlüssel.

Für rein mobile Workflows war USB lange unpraktisch. Mit NFC-Keys hat sich das geändert – aber nur, wenn eure Nextcloud-App den OAuth2-Flow über den Browser nutzt. Ältere Apps fallen hier durch.

Alternative: Passkeys via Bitwarden

Hier kommt eine clevere Lösung ins Spiel: Passkeys. Wenn ihr Bitwarden oder einen anderen modernen Passwort-Manager nutzt, könnt ihr bei der WebAuthn-Einrichtung in Nextcloud statt "Hardware-Sicherheitsschlüssel" die Option "Passkey mit Passwort-Manager" wählen. Bitwarden generiert dann einen FIDO2-Schlüssel und speichert ihn verschlüsselt in eurem Vault.

Falls ihr Bitwarden bereits in eurem Browser nutzt, kommt hier die Frage, wo der Sicherheitschlüssel gespeichert werden soll, entweder in eurem bestehenden Login Credentials für eure Nextcloud, oder eben auf dem Hardware-Key. Habt ihr keinen Yubikey, speichert ihr den Sicherheitsschlüssel auf eurem Bitwarden Account.

Die Vorteile:

• Immer dabei, wo euer Bitwarden ist (synchronisiert über alle Geräte)
• Kein physischer Key nötig – praktisch für Reisen oder Remote-Work
• Trotzdem phishing-resistent durch Domain-Binding (gleicher FIDO2-Standard wie YubiKey!)
• Günstiger: Keine Hardware-Kosten

Die Nachteile:

• Sicherheit hängt von eurem Bitwarden-Master-Passwort ab
• Bei kompromittiertem Vault ist auch der Passkey gefährdet
• Kein physischer "Besitz"-Faktor mehr

Die beste Strategie: Kombinieren!

Registriert in Nextcloud mehrere WebAuthn-Credentials:

1. YubiKey als primäre 2FA (maximale Sicherheit)
2. Bitwarden-Passkey als Backup (für Notfälle ohne Key)
3. Backup-Codes als letzte Rettung (ausgedruckt und sicher verwahrt)

So habt ihr maximale Sicherheit durch Hardware UND die Flexibilität eines Software-Passkeys. Nextcloud erlaubt problemlos mehrere WebAuthn-Geräte pro Account – nutzt das!

Admin-Notfallkit: occ-Befehle für den Ernstfall

Wenn bei der 2FA-Einrichtung etwas schiefgeht oder Nutzer ausgesperrt sind, braucht ihr SSH-Zugriff auf euren Server. Diese occ-Befehle retten euch:

2FA-Erzwingung deaktivieren (wenn ihr euch selbst ausgesperrt habt):

sudo -u www-data php occ twofactorauth:enforce --off

2FA für einzelnen Nutzer deaktivieren (Key verloren, Notfall):

sudo -u www-data php occ twofactorauth:disable <username> twofactor_webauthn

Beispiel:

sudo -u www-data php occ twofactorauth:disable admin twofactor_webauthn

2FA-Status eines Nutzers prüfen:

sudo -u www-data php occ twofactorauth:state <username>

Zeigt, welche 2FA-Provider aktiv sind.

Provider-Leichen aufräumen (nach Deinstallation einer 2FA-App):

sudo -u www-data php occ twofactorauth:cleanup twofactor_webauthn

⚠️ Warnung: Der Cleanup-Befehl ist irreversibel! Alle Nutzer müssen ihre WebAuthn-Keys danach neu registrieren. Nur verwenden, wenn ihr die App wirklich komplett entfernen wollt.

Docker-Nutzer aufgepasst: Ersetzt sudo -u www-data php occ durch:

docker exec -u www-data nextcloud php occ [restlicher Befehl]

Snap-Installation:

nextcloud.occ [restlicher Befehl]

Fazit

Ein YubiKey bringt euch nur dann echte Sicherheit, wenn ihr die richtige WebAuthn-Implementierung nutzt. Die integrierte "Passwortlos"-Funktion ist kein Ersatz für 2FA. Installiert die "Two-Factor WebAuthn" App, erzwingt 2FA, invalidiert alte Sessions – dann habt ihr Phishing-Schutz, der wirklich funktioniert.

Die Investition? 79 CHF für einen Key, ein paar Stunden Setup-Zeit. Der Gewinn? Eine ganze Klasse von Angriffen wird unmöglich. Wenn eure Nextcloud wichtige, sensible Daten enthält, ist das kein nice-to-have, sondern schlicht und einfach Pflicht.

Interessiert ihr euch für das Thema 2FA/Passkeys etwas tiefgreifender? Dann schaut mal hier vorbei.

The post Nextcloud mit U2F / Yubikey absichern appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist Solo-Mining überhaupt

Beim Solo-Mining versucht ein Miner auf eigene Faust, einen Bitcoin-Block zu finden. Im Gegensatz zum klassischen Pool-Mining, wo viele Miner ihre Rechenleistung bündeln und die Belohnung aufteilen, erhält der Solo-Miner die komplette Block-Belohnung (aktuell 3,125 BTC plus Transaktionsgebühren) - allerdings nur, wenn er tatsächlich einen Block findet.

Wer sich zuerst tiefer in das Thema Mining einlesen will, dem empfehlen wir hier unserer Solo Mining Bibel die euch die komplette verständlich näher bringen soll.

Die Rolle des Pools beim Solo-Mining

Hier liegt oft das Missverständnis: Auch beim Solo-Mining nutzen viele Miner einen Pool - aber dieser funktioniert völlig anders als beim herkömmlichen Pool-Mining. Der Pool dient lediglich als technische Infrastruktur:

• Er stellt die Blockvorlagen bereit (über einen Stratum-Server und einer verbunden Bitcoin Node)
• Er leitet gefundene Blöcke an das Bitcoin-Netzwerk weiter
• Er übernimmt die technische Kommunikation

Der Pool trägt aber keine eigene Hashrate bei. Er ist nur ein technischer Vermittler.

Fehlannahme Nr. 1: Die Pool-Größe beeinflusst die Chance

Desöfteren habe ich gehört, das Miner ihre Geräte mit Pools verbinden, die eine höhere Gesamt-Hashrate aufbringen, in der Annahme, dass dann die eigene Chance auch höher ist, einen Block zu finden. Beim Solo-Mining konkurriert jedoch jeder Miner direkt mit dem gesamten Bitcoin-Netzwerk - nicht nur mit seinem Pool. Die Wahrscheinlichkeit, einen Block zu finden, hängt ausschließlich von folgenden Faktoren ab:

1. Die eigene Hashrate - je mehr Rechenleistung, desto höher die Chance
2. Die globale Netzwerk-Hashrate - aktuell etwa 1000 EH/s
3. Glück - Block-Finding ist ein probabilistischer Prozess

Ob im gewählten Solo-Pool 100 EH/s oder nur 0,01 EH/s an Hashrate aktiv sind, macht für die eigenen Chancen absolut keinen Unterschied. Jeder Miner arbeitet isoliert und konkurriert mit allen Minern weltweit.

Fehlannahme Nr. 2: Mehr Workershares = höhere Block-Chance

Ein weit verbreiteter Irrtum ist die Annahme, dass eine höhere Anzahl an eingereichten Workershares die Wahrscheinlichkeit erhöht, einen Block zu finden. Das ist falsch.

Was sind nochmals Workershares

Workershares sind lediglich ein Arbeitsnachweis (Proof of Work), mit dem der Miner dem Pool zeigt, dass er tatsächlich arbeitet. Sie haben keinen direkten Einfluss darauf, ob ein Block gefunden wird oder nicht.

Unterschiedliche Share-Schwierigkeiten

Verschiedene Pools verwenden unterschiedliche Share Targets und da raus resultierende unterschiedliche Share-Difficulties:

• Pool A könnte eine niedrige Share-Difficulty verteilen → der Miner reicht viele Shares pro Minute ein
• Pool B könnte eine hohe Share-Difficulty verteilen → der Miner reicht wenige Shares pro Minute ein

In beiden Fällen bleibt die Wahrscheinlichkeit, einen tatsächlichen Block zu finden, absolut identisch. Die Share-Schwierigkeit beeinflusst nur die Häufigkeit der Kommunikation zwischen Miner und Pool, nicht die Mining-Effizienz.

Fehlannahme Nr. 3: Mehrere Geräte erhöhen die Chance gegenüber einem einzelnen Gerät

Ein weiteres hartnäckiges Missverständnis: Manche Miner glauben, dass vier Bitaxe mit je 1 TH/s eine höhere Chance auf einen Blockfund haben als ein einzelner NerdQAxe mit 4 TH/s. Das ist ein Trugschluss.

Nur die Gesamt-Hashrate zählt

Für das Bitcoin-Netzwerk ist es vollkommen irrelevant, ob die Hashrate von einem Gerät oder von hundert Geräten kommt. Entscheidend ist ausschließlich die Gesamt-Hashrate.

• 4x Bitaxe mit je 1 TH/s = 4 TH/s Gesamt-Hashrate
• 1x NerdQAxe mit 4 TH/s = 4 TH/s Gesamt-Hashrate

Die Wahrscheinlichkeit, einen Block zu finden, ist absolut identisch.

Warum entsteht dieses Missverständnis

Die Intuition sagt vielen: "Mehr Geräte = mehr Versuche = höhere Chance." Das stimmt prinzipiell - aber nur, weil mehr Geräte in der Regel auch mehr Gesamt-Hashrate bedeuten. Die Anzahl der Geräte selbst spielt keine Rolle.

Jeder Hash, den ein Miner berechnet, ist ein unabhängiger Versuch, einen Block zu finden. Ob diese Hashes von einem einzigen großen ASIC oder von vielen kleinen Geräten stammen, macht mathematisch keinen Unterschied. Das Netzwerk "sieht" nur die einzelnen Hash-Versuche, nicht die Geräte dahinter. Merkt euch deshalb, nur die Hashrate beeinflusst die Wahrscheinlichkeit einen Block zu finden, und nichts anderes.

Der einzige relevante Unterschied

Der praktische Unterschied liegt woanders: Bei mehreren Geräten hat man Redundanz. Fällt ein Bitaxe aus, laufen die anderen drei weiter. Fällt der NerdQAxe aus, steht man bei null. Aber das ist eine Frage der Ausfallsicherheit, nicht der Mining-Wahrscheinlichkeit.

Beim Mining berechnet der ASIC ständig Hashes. Ein Block wird nur dann gefunden, wenn ein Hash die extrem hohe Netzwerk-Schwierigkeit erfüllt. Die Workershares sind nur Zwischenmeldungen mit niedrigerer Schwierigkeit, um dem Pool zu zeigen: "Ich arbeite noch."

Analogie: Es ist wie beim Lottospielen - egal ob man dem Lottoanbieter jede Stunde oder jede Minute meldet, dass man noch Lose kauft, die Gewinnchance pro Los bleibt gleich.

Fehlannahme Nr. 4: Längere Laufzeit ohne Block erhöht die Chance

Eine psychologisch verständliche, aber mathematisch falsche Annahme: "Ich mine jetzt schon seit 1 Jahr ohne Block - langsam bin ich dran!" oder "Nach so langer Pechsträhne muss jetzt bald ein Block kommen!" Das ist der klassische Gambler's Fallacy - der Trugschluss des Spielers.

Jeder Hash-Versuch ist unabhängig

Beim Bitcoin-Mining ist jeder einzelne Hash-Versuch ein völlig unabhängiges Ereignis. Das bedeutet:

• Vergangenes Pech macht zukünftiges Glück nicht wahrscheinlicher
• Die Wartezeit hat keinen Einfluss auf die nächste Chance
• Der Miner hat kein "Gedächtnis" für vergangene Versuche

Analogie: Beim Würfeln bleibt die Chance auf eine Sechs bei jedem Wurf 1:6 - egal ob man vorher fünfmal oder fünfzigmal keine Sechs gewürfelt hat. Der Würfel "erinnert" sich nicht an vergangene Würfe.

Das Prinzip dahinter: Unabhängige Ereignisse

In der Wahrscheinlichkeitstheorie nennt man dies unabhängige Ereignisse. Die Wahrscheinlichkeit für Ereignis B wird nicht durch das Eintreten oder Nicht-Eintreten von Ereignis A beeinflusst.

Beim Mining bedeutet das konkret:

• Hash Nr. 1: Chance einen Block zu finden = eigene Hashrate / Netzwerk-Hashrate
• Hash Nr. 1.000.000: Chance einen Block zu finden = eigene Hashrate / Netzwerk-Hashrate
• Hash Nr. 1.000.000.000: Chance einen Block zu finden = eigene Hashrate / Netzwerk-Hashrate

Die Chance bleibt immer identisch, völlig unabhängig davon, wie viele erfolglose Versuche bereits hinter einem liegen.

Warum fühlt es sich anders an

Menschen neigen dazu, Muster zu sehen, wo keine sind. Nach einer langen Pechsträhne denkt man: "Jetzt muss es doch endlich klappen!" Diese Intuition ist evolutionär verständlich, aber mathematisch falsch.

Die einzige Ausnahme

Auch hier gilt, die Chance ändert sich nur, wenn sich die Rahmenbedingungen ändern:

• Die eigene Hashrate steigt (mehr Geräte, Übertaktung)
• Die Netzwerk-Hashrate sinkt (unwahrscheinlich auf lange Sicht)
• Die Difficulty wird angepasst (alle ~2 Wochen, reflektiert aber nur die Netzwerk-Hashrate)

Ansonsten gilt: Jeder Hash ist ein neuer, unabhängiger Versuch mit exakt der gleichen Wahrscheinlichkeit wie beim allerersten Hash.

Fehlannahme Nr. 5: Die niedrigste Latenz zum Pool erhöht eure Chancen wesentlich

Einige Pools werben mit besonders niedrigen Latenzen und versprechen euch deutlich bessere Chancen beim Solomining. Diese Aussage ist nur bedingt korrekt. Nach praktischen Erfahrungen macht es faktisch keinen Unterschied, wenn eure Latenz zum Pool bereits unter 100ms beträgt. Bei dieser Verbindungsgeschwindigkeit ist der neue Job so schnell bei eurem Miner angekommen, dass dieser keine veralteten Jobs mehr berechnet.

Sollte die Latenz zwischen 100-500ms liegen, könnte gelegentlich ein Share vom einem alten Job gesendet werden, bevor der neue vom Server ankommt. In der Praxis ist diese Wahrscheinlichkeit aber so gering, dass sie keinen messbaren Einfluss auf eure Chancen hat. Bei Latenzzeiten über 500ms wird man dann irgendwann doch langsam einen Anstieg an Rejected Shares bemerken, und man sollte sich überlegen, zu einem Server zu wechseln, der weniger weit weg ist.

Bei Home-Minern wie dem BitAxe ist dieser Faktor vollkommen irrelevant: Dass ausgerechnet dieser Share, der möglicherweise während des Latenz-Fensters gelöst wurde, der Block-Winner sein könnte, ist praktisch ausgeschlossen. Die Wahrscheinlichkeit, einen Block zu finden, ist bereits so gering, dass Millisekunden der Netzwerkverzögerung keinen messbaren Unterschied machen. Konzentriert euch stattdessen auf die Faktoren, die wirklich zählen – nicht auf die Millisekunden zum Pool.

Worauf sollte man beim Solo-Pool wirklich achten

Wenn die Pool-Größe und die Anzahl der Workershares keine Rolle spielen, was ist dann wichtig bei der Auswahl eines Solo-Pools?

Zuverlässigkeit: Der Pool sollte eine hohe Verfügbarkeit (Uptime) haben und niedrige Latenz bieten. Ausfallzeiten bedeuten verlorene Mining-Zeit.

Rejected Shares: Die tatsächlichen Anzahl der Rejected Shares, also der ablehnten Shares sollte möglichst tief sein. Rejected Shares sind das tatsächliche Result einer sehr hohen Netzwerklatenz oder instabilen Netzwerkverbindung. Rejected Shares entstehen, wenn der Mining Server die Arbeit angepasst hat, aber der Miner noch an einem alten Job / Template arbeitet, und diesen einreicht. Ein Wert von unter 0.25% ist in Ordnung.

Gebühren: Manche Solo-Pools verlangen über 2% Gebühr vom gefundenen Block. Bei 3,125 BTC kann das einen erheblichen Unterschied machen.

Technische Features: Unterstützung für moderne Mining-Technologien wie AsicBoost kann die Effizienz verbessern. Allerdings muss der Pool diese Features auch unterstützen.

Eigener Stratum-Server: Technisch versierte Miner können auch ihren eigenen Stratum-Server betreiben und sind dann komplett unabhängig von Drittanbietern. Hier ist dann auch die Latenz am niedrigstens. Mit einer Node aus unserem Shop, könnt ihr auch ganz einfach einen eigenen Pool betreiben!

Fazit

Die größten Fehlannahmen beim Solo-Mining auf einen Blick:

1. Die Größe des Pools hat keinerlei Einfluss auf die Wahrscheinlichkeit, einen Block zu finden
2. Die Anzahl der Workershares ist nur ein technischer Arbeitsnachweis und beeinflusst die Block-Finding-Chance nicht
3. Die Anzahl der Geräte spielt keine Rolle - nur die Gesamt-Hashrate zählt
4. Vergangenes Pech macht zukünftiges Glück nicht wahrscheinlicher - jeder Hash-Versuch ist ein unabhängiges Ereignis

Der Pool ist beim Solo-Mining lediglich technische Infrastruktur, keine Mining-Gemeinschaft. Die eigenen Chancen hängen ausschließlich von der eigenen Hashrate im Verhältnis zur globalen Netzwerk-Hashrate ab - und bei jedem einzelnen Hash-Versuch von einer gehörigen Portion Glück. Vergangene Versuche haben keinen Einfluss auf zukünftige Chancen.

Habt ihr Lust unserem Pool zu joinen? Schaut vorbei unter:

https://blitzpool.yourdevice.ch

The post Solo Mining - die grössten Fehlannahmen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das DOCX-Kompatibilitätsproblem

LibreOffice kann Dokumente im DOCX-Format speichern, dem Standardformat von Microsoft Word. Dennoch kann es vorkommen, dass ein MS Office-Nutzer eure Datei öffnet und das Layout anders aussieht als bei euch. Das liegt daran, dass beide Programme die Formatierungen intern unterschiedlich interpretieren.

Häufige Probleme beim DOCX-Austausch:

Schriftarten werden durch Standardschriften ersetzt, wenn sie beim Empfänger nicht installiert sind. Absatz- und Zeilenabstände können leicht variieren. Tabellen zeigen manchmal andere Spaltenbreiten oder Zellenformatierungen. Eingebettete Objekte wie Diagramme oder Formeln werden unterschiedlich dargestellt. Aufzählungen und Nummerierungen weichen in Einrückung und Abständen ab. Kopf- und Fußzeilen können ihre Position verändern.

Die Kompatibilität hat sich in den letzten Jahren deutlich verbessert, aber je komplexer euer Dokument formatiert ist, desto höher ist das Risiko für Abweichungen.

Die sichere Lösung: PDF statt DOCX

Wenn ihr sicherstellen möchten, dass euer Dokument beim Empfänger exakt so aussieht wie bei euch, ist PDF die bessere Wahl. LibreOffice bietet eine hervorragende PDF-Export-Funktion, die sogar mehr Optionen bietet als viele andere Programme.

So exportiert ihr in LibreOffice als PDF:

Öffnet das fertiges Dokument und geht auf "Datei" → "Exportieren als PDF" oder alternativ "Datei" → "Exportieren als" → "Als PDF exportieren". Es öffnet sich ein Dialog mit zahlreichen Einstellungsmöglichkeiten.

Die Standard Settings der PDF Einstellungen sind in den meissten Fällen absolut ausreichen. Wenn ihr möchtet, könnt ihr noch eine digitale Signatur hinzufügen.

Nützliche PDF-Optionen in LibreOffice:

Ihr könnt die Komprimierung anpassen, um die Dateigröße zu optimieren. Lesezeichen werden automatisch aus Überschriften erstellt, was die Navigation in langen Dokumenten erleichtert. Interaktive Formulare lassen sich direkt einbinden. Der PDF/A-Standard eignet sich für die Langzeitarchivierung. Wasserzeichen können hinzugefügt werden. Sicherheitseinstellungen wie Passwortschutz oder eingeschränkte Druckrechte sind möglich.

Wann DOCX, wann PDF

Verwendet DOCX, wenn:

• Der Empfänger das Dokument noch bearbeiten muss
• Ihr gemeinsam an einem Dokument arbeitet
• Einfache Formatierungen ausreichen

Verwendet PDF, wenn:

• Das Dokument finalisiert ist
• Die Formatierung exakt erhalten bleiben muss
• Ihr offizielle Dokumente versendet
• Der Empfänger das Dokument nur lesen und ausdrucken soll

Tipps für bessere DOCX-Kompatibilität

Falls ihr dennoch DOCX versendet müssen, helfen diese Maßnahmen:

Verwendet Sie Standardschriftarten wie Arial, Times New Roman oder Calibri – diese sind auf praktisch jedem System vorhanden. Haltet die Formatierung einfach und vermeidet Sie verschachtelte oder komplexe Layouts. Testet das Dokument, indem ihr es nach dem Speichern noch einmal öffnen und überprüft. Im Zweifelsfall schickt ihr zusätzlich eine PDF-Version mit, damit der Empfänger ein Referenzdokument hat.

Fazit

Der Dokumentenaustausch zwischen LibreOffice und Microsoft Office funktioniert in den meisten Fällen gut, ist aber nicht perfekt. Für wichtige Dokumente, bei denen die Formatierung stimmen muss, ist der PDF-Export die zuverlässigste Lösung. LibreOffice bietet hier professionelle Funktionen, die den Umstieg von Microsoft Office deutlich erleichtern.

The post LibreOffice und Microsoft Office: So vermeidet ihr Formatierungsprobleme appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Muster setzt sich fort mit der Copilot-Integration überall – von Paint bis Notepad. Microsoft drückt KI-Assistenten in jede Ecke von Windows 11 und macht es scheinbar unmöglich, sie zu deaktivieren.

Diese erzwungenen Ergänzungen haben ein gemeinsames Thema: Sie erfordern Internetverbindung und Cloud-Dienste. Microsoft will, dass eure Daten durch ihre Server fließen, verpackt als angeblich hilfreiche Features.

Jetzt hat Microsoft stillschweigend eine weitere kontroverse Änderung eingeführt, die Nutzern während der Windows 11-Installation die Wahlfreiheit nimmt.

Freiheit der Wahl? Was ist das

Microsoft testet eine Änderung, die alle bekannten Methoden blockiert, um während der initialen Windows 11-Einrichtung (OOBE) lokale Konten zu erstellen. Bisher konnten Nutzer einfache Befehle oder Tricks nutzen, um die Microsoft-Konto-Pflicht zu umgehen. Diese Workarounds funktionieren in den aktuell getesteten Insider Preview-Builds nicht mehr.

Windows Latest hat Build 26220.6772 in den Dev- und Beta-Kanälen getestet und bestätigt, dass keine der Umgehungsmethoden mehr funktioniert. Sollte diese Änderung in die stabilen Builds übernommen werden, müssten sich Windows 11 Home-Nutzer während der Ersteinrichtung mit einem Microsoft-Konto anmelden.

Windows 11 Pro-Nutzer haben noch eine Option (zumindest in den Test-Builds): Sie können Domain Join verwenden, um lokale Konten zu erstellen. Drittanbieter-Tools wie Rufus können ebenfalls genutzt werden, um modifizierte Installationsdateien zu erstellen, die diese Anforderung überspringen. Aber für normale Home Edition-Nutzer scheint Microsoft bereit zu sein, diese Wahlmöglichkeit komplett zu entfernen.

Was bedeutet das für die Privatsphäre

Diese Änderung ist aktuell in Insider Preview-Builds in den Dev- und Beta-Kanälen aktiv. Wenn Microsoft dem üblichen Rollout-Muster folgt, könnte sie innerhalb von zwei bis drei Monaten via Windows Update die stabilen Versionen erreichen.

Ein Microsoft-Konto bedeutet:

• Alle eure Aktivitäten werden mit eurer Identität verknüpft
• Telemetriedaten fließen direkt zu Microsoft und können eurem Account zugeordnet werden
• Cloud-Synchronisation ist standardmäßig aktiv – eure Einstellungen, Dateien und sogar Browser-Verläufe landen auf Microsoft-Servern
• Microsoft kann euren Zugang zu eurem eigenen Computer theoretisch sperren oder einschränken
• Eure E-Mail-Adresse wird zur Login-Kennung und Microsoft weiß genau, wer welchen PC nutzt

Mit einem lokalen Konto habt ihr deutlich mehr Kontrolle. Eure Daten bleiben lokal auf eurem Rechner, und ihr entscheidet selbst, was ihr teilen wollt. Keine automatische Cloud-Synchronisation, keine Verknüpfung eurer Aktivitäten mit einer zentralen Identität.

Die Doppelmoral von Microsoft

Und hier kommt der Knaller: Microsoft erlaubt es euch immer noch, das Microsoft-Konto nach Abschluss der Einrichtung zu entfernen. Ihr könnt euch während der Installation anmelden, den Desktop erreichen und dann sofort abmelden und ein lokales Konto erstellen.

Das lässt Microsofts Ausrede über "sicherzustellen, dass Geräte korrekt eingerichtet werden" wie kompletten Unsinn aussehen. Wenn ein Microsoft-Konto wirklich für die ordnungsgemäße Konfiguration notwendig wäre, warum dann die sofortige Entfernung erlauben? Es ist einfach nur ein weiteres Dark Pattern in ihrem Flaggschiff-Betriebssystem.

Die wahre Intention ist offensichtlich: Microsoft will möglichst viele Nutzer in ihr Ökosystem locken. Wer sich einmal mit einem Microsoft-Konto angemeldet hat, bei dem ist OneDrive aktiv, die Cloud-Synchronisation läuft, und die Telemetrie sammelt fleißig Daten. Die meisten Nutzer werden sich nicht die Mühe machen, das Konto nachträglich zu entfernen.

Das Timing ist verdächtig

Windows 10 erreichte sein End of Life am 14. Oktober 2025. Millionen von Nutzern werden nun unter Druck gesetzt, zu Windows 11 zu migrieren, und genau diese Einschränkung könnte auf sie warten.

Microsoft nutzt den Zwang zum Upgrade, um gleichzeitig die Kontrolle über eure Daten zu erhöhen. Wer von Windows 10 kommt und bisher vielleicht ein lokales Konto hatte, wird bei der Neuinstallation von Windows 11 gezwungen, ein Microsoft-Konto anzulegen. Viele werden es dabei belassen und sich nicht mehr die Mühe machen, es wieder zu entfernen.

Workarounds und Alternativen

Für technisch versierte Nutzer gibt es weiterhin Möglichkeiten:

Rufus für modifizierte Installationsmedien

Das Tool Rufus kann bootfähige USB-Sticks erstellen und dabei die Microsoft-Konto-Pflicht entfernen. Bei der Erstellung des Installationsmediums könnt ihr verschiedene Optionen aktivieren, darunter auch "Remove requirement for an online Microsoft account". Das funktioniert auch nach dieser Änderung noch, da Rufus die Installationsdateien selbst modifiziert.

Windows 11 Pro mit Domain Join

Wer Windows 11 Pro nutzt, hat weiterhin die Möglichkeit, während der Installation "Domain Join" zu wählen und damit ein lokales Konto zu erstellen. Diese Option bleibt auch in den aktuellen Test-Builds verfügbar – allerdings ist Windows 11 Pro deutlich teurer als die Home Edition.

Nachträgliche Kontoumwandlung

Wie bereits erwähnt, könnt ihr auch nach der Installation mit Microsoft-Konto zu einem lokalen Konto wechseln. Das ist zwar umständlich und genau das, was Microsoft bezweckt (die meisten werden es nicht tun), aber es funktioniert.

Linux als echte Alternative

Letztendlich bleibt festzuhalten: Der Wechsel zu Linux ist 2025 eine hervorragende Wahl.

Distributionen wie Ubuntu, Linux Mint, Pop!_OS oder Fedora sind mittlerweile so benutzerfreundlich, dass auch Einsteiger problemlos zurechtkommen. Die Installation ist oft einfacher als bei Windows, und ihr habt von Anfang an:

• Vollständige Kontrolle über euer System
• Keine Zwangs-Updates oder ungewollte Features
• Keine Telemetrie oder Datensammlung (außer ihr aktiviert sie explizit)
• Eine riesige Auswahl an freier und quelloffener Software
• Bessere Performance auf älterer Hardware
• Kein Konto-Zwang – ihr entscheidet, wie ihr euer System einrichtet

Für viele alltägliche Aufgaben – Browser, E-Mail, Office-Anwendungen, Multimedia – ist Linux mehr als ausreichend. Die Gaming-Situation hat sich durch Proton und Steam Deck massiv verbessert, und viele Windows-Programme lassen sich über Wine oder in virtuellen Maschinen nutzen.

Fazit

Microsoft zeigt einmal mehr, dass Nutzerfreundlichkeit und Wahlfreiheit keine Priorität haben. Stattdessen geht es um Datenkontrolle und Cloud-Anbindung. Die Entfernung der lokalen Konto-Option ist ein weiterer Schritt in diese Richtung – und das Timing zum Ende von Windows 10 ist alles andere als Zufall.

Für alle, die Wert auf Privatsphäre legen: 2025 ist ein guter Zeitpunkt, Alternativen ernsthaft in Betracht zu ziehen. Ob Linux als Hauptsystem oder zumindest als Dual-Boot-Option – die Kontrolle über eure eigenen Daten sollte nicht verhandelbar sein.

Hinweis: Falls ihr euch für einen Linux System aus unserem Shop entscheidet, und Dualboot mit Windows möchtet, kommt euer Windows System mit einem lokalen Systemadministrator Account eingerichtet daher, ohne Verbindung zu Microsoft.

The post Microsoft beendet lokale Konto-Einrichtung bei Windows 11 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Herzstück: Der BM1370-ASIC bleibt gleich

Beide Modelle setzen auf den gleichen Mining-Chip: den BM1370 von Bitmain, der auch im Antminer S21 Pro zum Einsatz kommt. Dieser ASIC-Chip liefert beeindruckende Leistungsdaten:

• Hashrate: 1,2 bis 1,3 TH/s (je nach Einstellungen und Kühlung)
• Effizienz: 15 J/TH (Joule pro Terahash) laut Herstellerangabe
• Leistungsaufnahme: etwa 18 bis 20 Watt im Standardbetrieb
• Technologie: Gleicher Chip wie im industriellen S21 Pro mit 195 BM1370-Chips

Die Hardware-Grundlage ist damit absolut identisch. Beide Versionen nutzen zudem denselben ESP32-S3-Microcontroller für die Steuerung und WLAN-Konnektivität sowie die gleiche AxeOS-Firmware für die Konfiguration über eine Weboberfläche. Die Einrichtung und die Einstellungen ist somit auch absolut identisch.

PCB-Revision 602: Produktionsoptimierung statt Performance-Upgrade

Der einzige echte Unterschied liegt im Design der Platine selbst. Die 602-Revision ist eine fertigungsoptimierte Version der 601-Platine:

Konkrete Änderungen am PCB:

• Entfernung ungenutzter Bauteilplätze (DNP – "Do Not Populate"), beispielsweise Position R18
• Optimiertes Routing der Leiterbahnen
• Vereinfachter Bestückungsprozess für zuverlässigere Serienproduktion
• Reduzierung potenzieller Fertigungsfehler durch weniger Komponenten

Diese Änderungen haben keinen direkten Einfluss auf die Mining-Performance. Bei identischer Kühlung liefern beide Versionen exakt die gleiche Hashrate und arbeiten mit der gleichen Effizienz.

USB-C: Verbesserte Apple-Kompatibilität

Ein praktischer Vorteil der 602-Revision zeigt sich bei der USB-Verbindung. Das überarbeitete Routing des USB-Datenpfads hat positive Nebenwirkungen:

• Stabilere USB-C-zu-USB-C-Verbindungen
• Weniger Kompatibilitätsprobleme mit MacBooks und anderen Apple-Geräten
• Zuverlässigere Firmware-Updates über USB-C

Bei der 601-Version traten gelegentlich Probleme beim Anschluss an Apple-Geräte auf – dieses Problem ist bei der 602-Variante weitgehend behoben.

Der wahre Unterschied: Bundle-Ausstattung

In der Praxis ist der wichtigste Unterschied zwischen den Modellen oft gar nicht die PCB-Revision, sondern die mitgelieferten Komponenten:

Viele Händler nutzen die 602-Revision als Gelegenheit, verbesserte Hardware-Pakete anzubieten:

Typische 602-Bundle-Vorteile:

• Größere, effizientere Kühlkörper (z.B. "Ice Tower" oder "Bitchin' Sink")
• Hochwertige, leisere Lüfter (oft Noctua-Modelle mit nur 25-30 dB)
• Verbesserte Wärmeableitung für stabileren Dauerbetrieb
• Teilweise Werksübertaktung auf 1,3 TH/s statt 1,2 TH/s

Diese Bundles ermöglichen oft höhere Taktraten und stabilere Temperaturen – allerdings nicht wegen der 602-Platine selbst, sondern wegen der besseren Kühlung.

Technischer Hintergrund: Das Bitaxe-Projekt

Bitaxe ist ein vollständig quelloffenes Bitcoin-Mining-Projekt mit dem Ziel, Mining zu dezentralisieren. Die Gamma-Serie ist bereits die fünfte Generation dieser kompakten Solo-Miner:

• Open-Source-Hardware: Sämtliche PCB-Designs und Stücklisten frei verfügbar auf GitHub
• Community-Entwicklung: Aktive Discord-Community "Open Source Miners United"
• Flexible Firmware: AxeOS ermöglicht Solo-Mining, Pool-Mining oder Lottery-Mining
• WiFi-Integration: Kein zusätzlicher Computer für den Betrieb nötig
• Plug & Play: Nach WLAN-Einrichtung direkt einsatzbereit

Praktische Kaufempfehlung

Für wen lohnt sich welche Version?

Bitaxe 601:

• Ausreichend für alle, die bereits gute Kühlkomponenten besitzen
• Preiswerter Einstieg ins Solo-Mining
• Selbst-Optimierung möglich (eigene Kühlkörper/Lüfter)

Bitaxe 602:

• Bessere Wahl für Apple-Nutzer (USB-C-Kompatibilität)
• Sinnvoll bei Bundle-Angeboten mit Premium-Kühlung
• Wenn du ein leises, thermisch stabiles Setup "out of the box" möchtest

Fazit: Marginale technische Unterschiede, merkliche Praxis-Vorteile

Die PCB-Revision 602 bringt keine Performance-Steigerung gegenüber der 601. Die Verbesserungen beschränken sich auf Fertigungsoptimierung und USB-Kompatibilität. Der eigentliche Mehrwert liegt meist in den besseren Bundles, die Händler mit der 602-Version anbieten.

Wer bereits einen Bitaxe 601 besitzt, muss nicht upgraden. Wer neu kauft und Wert auf leiseren Betrieb, bessere Kühlung oder Apple-Kompatibilität legt, greift zur 602-Version – idealerweise als Bundle mit Premium-Komponenten.

Wichtig zu wissen: Solo-Mining mit einem einzelnen Bitaxe ist ein Lotteriespiel mit extrem geringer Erfolgswahrscheinlichkeit, aber hoher pädagogischer Wirkung. Es geht primär um Dezentralisierung, technisches Verständnis und Spaß an der Technik – nicht um profitables Mining.

Lust auf auf einen Bitaxe 602? Schaut mal im Shop vorbei:

The post Unterschied Bitaxe Gamma 601 vs 602 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung zeigt dir die Installation von VeraCrypt unter Ubuntu 24.04 und erklärt, wie ihr verschlüsselte Container per Terminal oder grafischer Benutzeroberfläche erstellen und nutzen könnt.

Was ist VeraCrypt und wie unterscheidet es sich von ecryptfs oder fscrypt

VeraCrypt, ecryptfs und fscrypt verfolgen alle dasselbe Ziel – den Schutz eurer Daten durch Verschlüsselung – gehen dabei aber unterschiedliche Wege.

VeraCrypt arbeitet container-basiert: Ihr erstellt eine verschlüsselte Datei (den Container), die nach dem Entsperren wie ein normales Laufwerk eingebunden wird. Der große Vorteil ist die Plattformunabhängigkeit – derselbe Container lässt sich unter Linux, Windows und macOS öffnen. Zusätzlich bietet VeraCrypt Funktionen wie versteckte Volumes und glaubhafte Abstreitbarkeit.

ecryptfs verschlüsselt dagegen auf Dateisystemebene. Jede Datei wird einzeln verschlüsselt und behält ihren Dateinamen (optional auch verschlüsselt). Ubuntu nutzte ecryptfs früher für die Home-Verzeichnis-Verschlüsselung. Das zugehörige Paket heißt ecryptfs-utils. Die Entwicklung ist allerdings weitgehend eingestellt.

fscrypt ist der moderne Nachfolger von ecryptfs und nutzt die native Verschlüsselung des Linux-Kernels für ext4, F2FS und UBIFS. Es ist schlanker und wird aktiv weiterentwickelt. Ubuntu setzt seit Version 18.04 auf fscrypt statt ecryptfs.

Kurz zusammengefasst: VeraCrypt eignet sich besonders, wenn ihr portable Container oder plattformübergreifende Kompatibilität braucht. fscrypt ist die erste Wahl für die Verschlüsselung von Verzeichnissen direkt im Dateisystem unter Linux.

Voraussetzungen

• Ein laufendes System mit Ubuntu 22.04/24.04, Linux Mint, oder Debian

VeraCrypt installieren

Da VeraCrypt nicht in den Standard-Repositories der meissten Linux Distros enthalten ist, müsst ihr das vertrauenswürdige Unit 193 PPA hinzufügen, um Zugriff auf die aktuelle Version zu erhalten. Folgt den nachstehenden Schritten zur Installation:

1. Schritt: Paketquellen aktualisieren

sudo apt update

2. Schritt: VeraCrypt-PPA hinzufügen

sudo add-apt-repository ppa:unit193/encryption -y

3. Schritt: Paketindex erneut aktualisieren

sudo apt update

4. Schritt: VeraCrypt installieren

sudo apt install veracrypt -y

5. Schritt: Installation prüfen

veracrypt --version

Erwartete Ausgabe:

VeraCrypt 1.26.14

Verschlüsselte Volumes mit VeraCrypt erstellen

Mit VeraCrypt könnt ihr eure Daten schützen, indem ihr komplette Volumes verschlüsselt. Ähnlich wie bei fscrypt oder ecryptfs lassen sich neue Container erstellen oder externe Speichermedien absichern. Die folgenden Schritte zeigen euch, wie ihr unter Ubuntu 24.04 Volumes verschlüsselt.

Volumes über die Kommandozeile unter Ubuntu 24.04 verschlüsseln

Erstellt zunächst ein neues Arbeitsverzeichnis:

mkdir sample-dir

Wechsle in das erstellte Verzeichnis:

cd sample-dir

Jetzt erstellt ihr das verschlüsselte Volume mit folgendem Befehl:

sudo veracrypt --text --create vctest.vc --size 200M --password DeinPasswort --volume-type normal --encryption AES --hash sha-512 --filesystem ext4 --pim 0 --keyfiles "" --random-source /dev/urandom

Erklärung der Parameter:

• --text: Nutzung im Terminal ohne grafische Oberfläche.
• --create: Legt den Namen der verschlüsselten Datei fest.
• --size: Gibt die gewünschte Größe des Volumes an, z. B. 200M für 200 MB.
• --password: Passwort für das Volume – am besten 20 Zeichen oder mehr.
• --volume-type: Erstellt ein Standard-Volume.
• --encryption: Verschlüsselungsalgorithmus (hier AES).
• --hash: Hashfunktion zur Schlüsselableitung (hier SHA-512).
• --filesystem: Format des Volumes, z. B. ext4.
• --pim: Personal Iterations Multiplier – 0 bedeutet Standardwert.
• --keyfiles: Keine Schlüsseldateien – daher leerer String.
• --random-source: Zufallsquelle für die Schlüsselgenerierung (hier das System-Zufallsgerät).

Dieser Befehl erstellt ein 200MB großes Volume namens vctest.vc mit AES-Verschlüsselung, SHA-512 als Hash und ext4-Dateisystem. Grösse und Namen können natürlich angepasst werden.

Erwartete Ausgabe:

Done: 100.000% Speed: 79 MiB/s Left: 0 s
The VeraCrypt volume has been successfully created.

VeraCrypt-Volume einbinden (mounten)

Mit folgendem Befehl bindet ihr das Volume im Verzeichnis /mnt ein:

sudo veracrypt --text --mount vctest.vc /mnt --password EnterYourPassword1! --pim 0 --keyfiles "" --protect-hidden no --slot 1 --verbose

Erklärung der Optionen:

• –mount: Zielverzeichnis für das eingehängte Volume.
• –slot: Verwendeter Slot für die Einbindung.
• –verbose: Zeigt Fortschritt und Details beim Einhängen.

Erwartete Ausgabe:

Volume /home/example_user/dir1/vctest.vc has been mounted.

Wechslet ins eingehängte Verzeichnis, um auf die verschlüsselten Daten zuzugreifen:

cd /mnt

Ihr könnt nun Dateien in diesem geschützten Verzeichnis lesen und schreiben.

Liste der aktuell gemounteten VeraCrypt-Volumes anzeigen:

veracrypt --list

Erwartete Ausgabe:

1: /home/linuxuser/vctest.vc /dev/mapper/veracrypt1 /mnt

VeraCrypt-Volumes aushängen (unmounten)

Wechselt zunächst zurück in dein Home-Verzeichnis:

cd

Volume anhand des Dateinamens aushängen:

sudo veracrypt --dismount vctest.vc

Oder anhand des Mount-Pfades:

sudo veracrypt --dismount /mnt

Oder über den Slot:

sudo veracrypt --text --dismount --slot 1

Alle aktiven Volumes auf einmal aushängen:

sudo veracrypt --dismount

Abschließend prüfen, ob keine Volumes mehr eingebunden sind:

veracrypt --list

Erwartete Ausgabe:

Error: No volumes mounted.

VeraCrypt-GUI unter Ubuntu 24.04 verwenden

Jetzt habt ihr gelernt, wie ihr verschlüsselte Container über die Kommandozeile erstellt, nun zeigen wir natürlich auch die Variante über die integrierte GUI Oberfläche von Veracrypt. Diese Methode ist besonders benutzerfreundlich und verzichtet vollständig auf Befehle in der Konsole. Die folgenden Schritte zeigen euch, wie ihr mit der GUI verschlüsselte Container erstellt.

VeraCrypt-GUI starten

• Geht ins Anwendungsmenu eurer Distro.
• Sucht und wählt VeraCrypt aus der Liste aus und starte das Programm.
• Klickt im geöffneten Fenster auf Volumen erstellen.

Ein neues verschlüsseltes Volume erstellen

• Wählt zwischen Verschlüsselte Container Datei erstellen (klassischer Container) oder Partition bzw. Laufwerk verschlüsseln. Wir verwenden zuerst mal die Container erstellen wie auf der Kommando Zeile. Danach könnt ihr noch zwischen einem Standard, oder einem verstecktem Container auswählen. Der versteckte Container ist nicht direkt sichtbar.
• Klicke auf Select File, um den Speicherort der Containerdatei festzulegen.

• Wählt einen Ordner aus, gib einen Namen wie MyData ein und klickt auf Save.
• Überprüfe den Pfad und klicke auf Weiter.

Verschlüsselung und Volume-Größe festlegen

• Wähle einen Verschlüsselungsalgorithmus wie AES und eine Hashfunktion wie SHA-512.
• Klickt auf Weiter, um die gewünschte Größe des Volumes zu bestimmen.
• Trage die Größe ein und klicke erneut auf Weiter.

Passwort und PIM einstellen

• Lege ein starkes Passwort zur Sicherung des Volumes fest.
• Falls gewünscht, aktiviere PIM (Personal Iterations Multiplier) für zusätzliche Sicherheit.
• Gib einen PIM-Wert ein oder nutzt am besten 0 (entspricht 458 Iterationen).

Dateisystem auswählen und Volume abschließen

• Wähle ein Dateisystem aus, z.B FAT für eine Plattformübergreifende Nutzung. Danach wählt aus, ob der Container auch auf anderen Linux Installationen mit VeraCrypt geöffnet werden darf, Beachtet dass ihr für Windowssyteme NTFS oder FAT verwenden müsst, soll es nur auf anderen Linux funktioniert könnt ihr als Dateiensystem auch ext4 nehmen.
• Bewege deine Maus zufällig im Fenster, um kryptografische Stärke zu erhöhen, und klicke dann auf Format.
• Bewegt euren Mauszeiger danach 30 Sekunden über das Veracrypt Fenster, dass verschafft eine zusätzliche Entropie und erzeugt eine weitere Verschlüsselungsschicht. Klickt danach auf Formatieren.
• Wenn das Volume erstellt wurde, klicke auf Schliessen, um den Assistenten zu beenden.

Verschlüsseltes Volume einbinden

• Klickt in der Hauptansicht von VeraCrypt auf Datei und wählt euer erstelltes Volume aus.
• Klicke auf Einhängen und gib das Passwort und die PIM Zahl ein ein.
• Nach erfolgreichem Einbinden wird das Volume im VeraCrypt-Fenster angezeigt und kann verwendet werden.

Nun seht ihr einen Eintrag in der Liste auf der VC Oberfläche. Mit einem Doppelklick, öffnet sich auch gleich das Volumen. Danach habt ihr den Ordner wie ein zusätzliches Laufwerk zur Verfügung und könnt darin Datein, Bilder, Dokumente und sonstwas ableben:

Verschlüsslung von Datenträgern und Volumen

Der Ablauf ist genau der gleiche, ausser dass ihr keine Datei erstellt, sondern eine Partition, oder ein Laufwerk komplett verschlüsselt. Bei dem Schritt wo ihr eine Datei erstellt, wählt ihr einfach ein freies, leeres Laufwerk aus!

Bitte stellt stellt ihr 100% Sicher, dass ihr nicht ausversehen das falsche Laufwerk verschlüsselt, den das Laufwerk wird vorher komplett bereinigt und gelöscht!

Anschliessend wählt ihr anstatt Datei, einfach den Datenträger aus, der eingehängt werden soll.

Auf einem anderen System verwenden

Ihr könnt nun einfach die verschlüsselte Containerdatei via USB Stick auf einem anderen Rechner mit Veracrypt öffnen, indem ihr die Datei auswählt, und wieder entsprechend einhängt.

Optional: VeraCrypt unter Ubuntu 24.04 deinstallieren

Wenn ihr VeraCrypt nicht mehr benötigt, könnt ihr es mit den folgenden Schritten von deinem Ubuntu-System entfernen:

1. Schritt: VeraCrypt deinstallieren

sudo apt autoremove veracrypt -y

2. Schritt: VeraCrypt-PPA entfernen

sudo add-apt-repository --remove ppa:unit193/encryption -y

3. Schritt: Paketquellen aktualisieren

sudo apt update

Fazit

Damit habt ihr VeraCrypt erfolgreich unter Ubuntu 24.04 installiert und die grundlegende Handhabung kennengelernt – sowohl per Kommandozeile als auch über die grafische Benutzeroberfläche. Die Software bietet euch eine solide Möglichkeit, sensible Daten auf Datei-, Ordner- oder Laufwerksebene zu verschlüsseln. Wer tiefer einsteigen möchte, findet in der offiziellen VeraCrypt-Dokumentation weitere Optionen wie versteckte Volumes oder die Nutzung von Keyfiles.

Veracrypt stellt eine gute Alternative dar, falls das Homeverzeichnis nicht Standardmässig verschlüsselt habt, und ihr bestimmte Daten zusätzlich absichern wollt.

The post VeraCrypt unter Linux installieren und nutzen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Im Kern geht es bei Nostr darum, Kommunikation – egal ob kurze Posts, Chats, Zahlungen oder News – dezentral, zensurresistent und offen zu gestalten. Ein nachträgliches Löschen, vom Betreiber, wie es z.B aus den Twitter Files bekannt geworden ist, ist nicht möglich, da es keinen zentralen Betreiber gibt.

Wie Nostr funktioniert

Anstatt eines zentralen Servers, auf dem alle Daten gespeichert werden (wie bei Twitter oder X), funktioniert Nostr über ein Netzwerk aus sogenannten Relays.

• Jeder kann einen Relay-Server betreiben.
• Nutzer (Clients) verbinden sich mit beliebigen Relays, um Nachrichten zu senden oder zu empfangen.
• Ein Relay speichert und verteilt diese Nachrichten, hat aber keine Kontrolle über die Identitäten oder Inhalte.

Jeder Nutzer besitzt ein Kryptoschlüsselpaar:

• Der private Schlüssel dient zum Signieren von Nachrichten (vergleichbar mit einer digitalen Unterschrift).
• Der öffentliche Schlüssel ist die Identität des Nutzers (vergleichbar mit einem Benutzernamen, nur kryptografisch eindeutig).

Damit ist die Authentifizierung vollständig ohne Passwort, ohne zentrale Datenbank und ohne Plattformkonto möglich.

Das Login Verfahren

Ein Nostr Schlüsselpaar sieht in der Regel so aus:

Privater Schlüssel (nsec…): nsec1x5yq3t7hd2u9a6g9j3p2q9ld0z3w7mxyz…
Öffentlicher Schlüssel (npub…): npub1w9r3v5q9j8t5u2c4n8z9s7g4l6d3v8kxyz…

Diese beiden Schlüssel sind das Fundament Eurer Identität im gesamten Nostr-Netzwerk. Der private Schlüssel ist Euer persönlicher Zugang – er funktioniert wie ein Passwort, mit dem Ihr alle Eure Nachrichten digital unterschreibt (das passiert automatisch im Hintergrund). Der öffentliche Schlüssel dagegen ist Euer Benutzername, über den Euch andere Nutzer finden, folgen oder Euch Nachrichten senden könnt.

Wie das Login-Verfahren funktioniert

Wenn Ihr Euch bei einem Nostr-Client anmeldet (z. B. Damus, Primal, Snort, Amethyst oder Iris), läuft das im Gegensatz zu herkömmlichen Plattformen völlig anders ab.
Es gibt keine Registrierung, keine E-Mail-Adresse, kein Passwort. Stattdessen wird einfach Euer Schlüsselpaar verwendet.

Der Ablauf sieht so aus:

1. Ihr gebt Euren privaten Schlüssel (oder besser: nutzt eine externe Schlüsselverwaltung, siehe unten).
2. Der Client verwendet diesen Schlüssel, um Eure Aktionen (z. B. Posts, Likes, Direktnachrichten) digital zu signieren.
3. Über den öffentlichen Schlüssel kann jeder verifizieren, dass die Nachricht tatsächlich von Euch stammen.

So entsteht eine selbstsouveräne Authentifizierung, die keiner Plattform gehört. Dein Account ist universell gültig – Ihr könnt Euch mit denselben Schlüsseln in jedem beliebigen Nostr-Client anmelden, und Euer Profil, Eure Posts und Kontakte bleiben erhalten.

Account Erstellung

Geht z.B. auf primal.net, und klickt in der rechten Leiste unten auf Get Started. Es öffnet sich ein Fenster. Hier wählt Ihr Create Account aus.

Im Nächsten Schritt, wählt Ihr einen Username und einen Displayname (dieser wird öffentlich angezeigt).

Danach könnt Ihr ein paar Account Details eingeben, einen Avatar festlegen, eine kurze Beschreibung über Euch festlegen, Eure Webseite, oder eine LN-Adresse angeben, falls ihr eine habt:

Im nächsten Schritt werden Euch ein paar Accounts angezeigt, denen Ihr folgen könnt. Müsst Ihr aber nicht, ihr könnt unten einfach auf den Finish Button klicken.

Für das Login könnt ihr einen PIN festlegen, welchen euren Schlüssel zusätzlich absichert (nur für den jeweiligen Client und nicht universel gültig!).

Damit Ihr Euren Zugang niemals verliert, solltet Ihr Euch nun euren Privaten Schlüssel extrahieren. Damit könnt ihr später AlbyHub (die externe Schlüsselverwaltung) verknüpfen, oder Euch auf anderen Clients einloggen. Geht dafür auf die Settings, und dann auf Account:

Hier unbedingt den Private Key kopieren, und z.B in einem Passwortmanager sichern. Der Key gehört am besten nicht irgendwo als Klartext in einer Datei auf Eurem Rechner gespeichert. Mit dem PrivateKey hat jeder vollständigen Zugriff auf Euer Profil!

Mit dem Privatekey könnt Ihr Euch dann auch in anderen Nostr Clients anmelden. Auf Iris.to geht ihr dann Beispielsweise einfach auf Login, und wählt als Loginmethode Paste Privatekey or Public Key.

Sicherheit und Handhabung der Schlüssel

Der private Schlüssel ist extrem sensibel – wer ihn besitzt, kontrolliert Euren Account vollständig. Es gibt kein „Passwort zurücksetzen“ oder Support-Team, das ihn wiederherstellt. Deshalb ist ein sicherer Umgang entscheidend:

• Nie den privaten Schlüssel weitergeben.
• Offline sichern, z. B. in einem Passwort-Manager oder auf Papier (ähnlich wie bei einem Bitcoin Seed).
• Nicht im Browser speichern, falls der Client dies anbietet – lieber über eine separate Wallet oder Erweiterung einloggen.
• Schlüsselverwaltungsextention: z.B. Albyhub verwenden.

Viele moderne Nostr-Clients nutzen bereits NIP-07, eine standardisierte Schnittstelle für Browsererweiterungen (z. B. Alby, nos2x, Blockcore Vault). Diese Erweiterungen fungieren wie eine Nostr-Wallet und verhindern, dass Ihr Euren privaten Schlüssel direkt eingeben musst.

Damit ähnelt das Ganze dem Login mit einer Bitcoin-Wallet:
Der Client fordert eine Signatur an, Ihr bestätigst sie über Eure Schlüsselverwaltung, und der Login ist abgeschlossen – ohne dass Euer Schlüssel jemals das Gerät verlässt.

Der Unterschied zu klassischen Logins

Bedienung der Clients oder des Protokols

Die Bedienung von Nostr ist im Grunde ganz vertraut: Ihr postet kurze Nachrichten, könnt anderen folgen, Beiträge liken, teilen oder kommentieren – genau wie auf Twitter oder anderen sozialen Netzwerken. Der Hauptunterschied liegt eher unter der Haube: Eure Daten liegen nicht bei einer Firma, sondern auf offenen Relays, und Euer Login läuft über Euren Schlüssel, nicht über ein Passwort. Für den Nutzer fühlt sich das aber kaum anders an – moderne Clients wie Damus, Snort oder Primal sind so aufgebaut, dass sie sich intuitiv wie jede andere Social-Media-App bedienen lassen.

Welche Clients gibt es

Es gibt mittlerweile eine ganze Reihe an Nostr-Clients, also Anwendungen, mit denen man das Protokoll nutzen kann. Für iOS ist der bekannteste Damus, auf Android Amethyst, und im Browser greifen viele zu Snort, Primal, oder Iris. Sie alle basieren auf denselben Nostr-Grundlagen, unterscheiden sich aber in Bedienung, Design und Zusatzfunktionen – etwa bei der Darstellung von Feeds, Chat-Funktionen oder der Integration von Lightning-Zahlungen über „Zaps“.

Damit Ihr Euch nicht jedes Mal mit deinem privaten Schlüssel einloggen musst, gibt es wie gesagt Browser-Erweiterungen wie Alby bzw. Alby Hub. Diese Erweiterung dient als sicherer Signer für Nostr und Lightning zugleich.
Statt den privaten Schlüssel direkt in einem Client einzugeben (was riskant wäre), speichert Alby ihn verschlüsselt lokal und signiert Anfragen nur dann, wenn Ihr sie aktiv bestätigt.

Das Prinzip funktioniert ähnlich wie eine Krypto-Wallet:

• Der Client (z. B. Snort oder Primal) fragt über die NIP-07-Schnittstelle eine Signatur an.
• Die Alby-Extension bestätigt oder lehnt diese ab.
• Euer privater Schlüssel bleibt dabei immer unter Eurer Kontrolle und verlässt nie die sichere Umgebung der Erweiterung.

Mit Alby Hub könnt Ihr außerdem mehrere Identitäten verwalten, Relays konfigurieren und sogar Lightning-Zahlungen direkt aus der Erweiterung heraus abwickeln. Damit ist Alby eine Art Schaltzentrale für alle Eurer Nostr- und Lightning-Aktivitäten – bequem, sicher und komplett selbstbestimmt. Wie wir AlbyHub einrichten, beschreiben wir in einem weiteren Beitrag demnächst.

Was macht Nostr so besonders

a) Zensurresistenz
Da jeder einen Relay betreiben kann, lässt sich niemand wirklich aussperren. Selbst wenn ein Relay Eure Beiträge blockiert, könnt Ihr sie einfach über andere Relays verbreiten. Diese Offenheit macht Nostr besonders attraktiv für Menschen in Ländern mit eingeschränkter Meinungsfreiheit.

b) Kein zentraler Eigentümer
Es gibt keine Firma, die entscheidet, was erlaubt ist, wie der Algorithmus funktioniert oder wessen Account gesperrt wird. Das Netzwerk gehört allen – oder besser gesagt: niemandem. Nostr ist dezentraler als Mastodon, da hier zum Beispiel einfach der jeweilige Mastodon Server offlinen genommen werden könnte, und alle Accounts die sich auf dieser Mastodon Instanz befinden, wären weg vom Fenster.

c) Kryptografische Identität
Deine Identität hängt nicht von einer Plattform ab. Wenn Ihr Euren öffentlichen Schlüssel habt, könnt Ihr ihn in jedem beliebigen Client (z. B. Damus, Amethyst, Snort, Primal oder Iris) nutzen und seit sofort wieder „Ihr“. Kein Reset, kein Login über E-Mail, keine Datenweitergabe.

d) Offene Standards und Erweiterbarkeit
Nostr ist modular aufgebaut. Neue Funktionen wie Gruppen, Chats, Zahlungen oder Reaktionen werden durch sogenannte NIPs (Nostr Improvement Proposals) standardisiert – ähnlich wie bei Bitcoin oder dem Internet selbst. So wächst das Ökosystem kontinuierlich.

e) Bitcoin-Integration
Viele Nostr-Clients unterstützen Lightning-Zahlungen über zaps – das sind Mikrotransaktionen, mit denen Nutzer sich gegenseitig belohnen können. Diese enge Verbindung zwischen sozialer Interaktion und Bitcoin ist einzigartig und ermöglicht ein völlig neues Modell für Inhalte im Netz.

Der Unterschied zu Twitter, Mastodon & Co

Warum Nostr zukunftsweisend ist

Nostr stellt die digitale Souveränität wieder her. In einer Zeit, in der Plattformen den Informationsfluss kontrollieren und Algorithmen Meinungen formen, bietet Nostr einen radikal anderen Ansatz:

• Keine Werbung, keine Datenanalyse.
• Keine Sperrungen wegen Meinungsäußerungen.
• Kein Verlust des Accounts bei Plattformwechsel.
• Inhalte gehören dem Nutzer selbst.

Damit wird Nostr zu einer Art digitalem Rückgrat für freie Kommunikation – offen wie das Internet in seinen Anfangstagen, aber mit moderner Kryptografie und optionaler Bitcoin-Integration.

Aktuelle Probleme

Natürlich ist Nostr nicht perfekt:

• Bedienung ist für Neulinge ungewohnt, da Schlüsselverwaltung und Relays Verständnis erfordern.
• Performance hängt stark von der Wahl der Relays ab. Teilweise funktioniert mal der Client eine Weile lang nicht.
• Privatsphäre: Relays sehen Eure öffentliche Aktivität, daher ist die Nutzung von vertrauenswürdigen oder selbstgehosteten Relays sinnvoll.
• Nicht immer aktuell: Es kann sein, dass ihr bestimmte Posts eine Weile lang nicht seht, weil sie sich noch nicht auf dem Relay befinden, mit dem ihr verbunden seit.

Trotzdem schreitet die Entwicklung schnell voran – es gibt bereits Chatfunktionen, verschlüsselte Direktnachrichten, Suchdienste, Content-Feeds, Musikplattformen und sogar komplette Marktplätze (wie z. B. Satoshis Kleinanzeigen) auf Basis von Nostr.

Fazit

Nostr ist mehr als nur eine Alternative zu Twitter – es ist ein völlig neues Paradigma für soziale Kommunikation im Internet.
Anstatt Nutzer in zentralisierten Plattformen einzusperren, gibt Nostr ihnen die volle Kontrolle über Identität, Inhalte und Interaktion zurück.

Wer die Vision des freien Internets teilt, findet in Nostr ein Werkzeug, das diesen Geist wiederbelebt – unabhängig, offen, global und unzensierbar.

The post Nostr – Das freie, zensurresistente soziale Netzwerk appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Nun steht ein bedeutender Wandel bevor: Das GrapheneOS-Team arbeitet aktiv mit einem großen Smartphone-Hersteller zusammen, um erstmals auch Nicht-Pixel-Geräte zu unterstützen. Damit wird die bisherige Abhängigkeit von Googles Hardwarestrategie Schritt für Schritt aufgelöst.

Was ist geschehen

Google hat sich dazu entschieden, ab dem Pixel 10, keine Firmwareblobs für die Geräte in ihren Device-Tree mehr auszuliefern angeblich der Effizienz wegen, und um den Code der Releases schlank zu halten. Ein entscheidender Punkt, der oft übersehen wird, ist, wie sehr diese neuen Hürden Googles die Geschwindigkeit von Projekten wie GrapheneOS ausbremsen. GrapheneOS ist bekannt dafür, sehr schnell nach einem neuen Android-Release eine stabile, gehärtete Version für Pixel-Geräte bereitzustellen. Diese schnelle Taktung war bislang überhaupt nur möglich, weil Google die nötigen Bausteine – also Device-Trees, Kernel-Quellen und Treiber-Binaries – zeitnah veröffentlicht hat.

Genau diese Grundlagen fehlen jetzt.

Anstatt die neue Android-Version „einfach“ wie gewohnt in ihr eigenes Sicherheits-Framework einzubauen, müssen die Entwickler nun zuerst versuchen, veraltete Device-Trees aus der vorherigen Version anzupassen, Treiber aus Binärblobs mühselig zu reverse engineeren oder im schlimmsten Fall die gesamte Gerätebeschreibung komplett neu zu schreiben. Das bedeutet:

• Jeder Release erfordert deutlich mehr Arbeitsstunden allein für die technische Basis.
• Die gewohnte „Release-Nähe“ zu Googles offiziellen Pixel-Updates kann nicht mehr gehalten werden.
• Fehler und Inkompatibilitäten schleichen sich zwangsläufig häufiger ein, weil vieles nicht mehr dokumentiert, sondern erraten oder rekonstruiert werden muss.

Für ein Projekt wie GrapheneOS, das höchsten Sicherheitsansprüchen gerecht werden will und keinerlei Kompromisse bei der Systemintegrität eingeht, ist das ein echter Klotz am Bein.

Andere Custom-ROMs können an manchen Stellen pragmatischer arbeiten, etwa indem sie provisorische Treiber einbauen oder Teile des Systems nur oberflächlich anpassen. GrapheneOS hingegen arbeitet auf Kernel- und Hardwaresicherheitsniveau. Das bedeutet, jeder fehlende oder fehlerhafte Baustein muss sauber und sicher ersetzt werden – sonst wird nicht veröffentlicht.

Und genau das erklärt auch, warum GrapheneOS nicht mehr so schnell neue Versionen herausbringen kann wie früher. Diese künstlichen Barrieren sind kein kleines Hindernis, sondern ein echter Bremsklotz, der die gesamte Entwicklungsdynamik des Projekts verändert hat.

Aus diesem Grund ist auch der Schritt zur Zusammenarbeit mit einem OEM so logisch: Wenn der Hersteller selbst die nötigen Ressourcen bereitstellt, müssen die Entwickler nicht mehr monatelang im Dunkeln stochern, sondern können wieder mit kalkulierbaren Entwicklungszeiten arbeiten – und damit ihre Releases wieder zeitnah und stabil liefern.

Ein High-End-Flaggschiff als neue Plattform

Laut Aussagen eines GrapheneOS-Moderators im offiziellen Subreddit arbeitet das Projekt derzeit mit einem großen OEM (Original Equipment Manufacturer) zusammen. Das Ziel: ein Smartphone auf Basis bereits bestehender High-End-Hardware mit einer offiziellen GrapheneOS-Unterstützung.

Konkret soll das Gerät mit dem aktuellen Snapdragon 8 Elite Gen 5 ausgestattet sein. Dieser wurde erst Ende September vorgestellt und liefert sowohl bei CPU- als auch bei GPU-Leistung spürbar mehr Performance als aktuelle Pixel-Modelle. Die Snapdragon-Plattform bringt außerdem erstklassige Hardware-Komponenten mit:

• Hochwertige Kommunikationsmodule: Modernes Wi-Fi, Bluetooth, GNSS sowie eSIM-Unterstützung.
• Leistungsfähige Signalverarbeitung: Snapdragon-SoCs verfügen über ausgereifte ISP- und NPU-Komponenten, was nicht nur Kameraqualität verbessert, sondern auch lokale KI-Funktionen effizient beschleunigt.
• Langfristige Update-Perspektive: Durch die enge Zusammenarbeit mit dem OEM erhalten die GrapheneOS-Entwickler frühzeitig Zugriff auf Treiber, Kernelquellen und sicherheitsrelevante Firmware.

Preislich soll das neue Gerät in der gleichen Liga wie die Pixel-Modelle spielen und breit verfügbar sein – also nicht nur in einzelnen Regionen, sondern in mehreren Märkten weltweit.

Warum dieser Schritt für GrapheneOS so wichtig ist

In einem weiteren Statement erklärte das Projektteam, dass die derzeit am Markt verfügbaren Geräte des Partners zwar noch nicht die extrem hohen Sicherheitsanforderungen von GrapheneOS erfüllen, aber eine kommende Geräteserie diese Anforderungen explizit erfüllen wird.

Damit entsteht für das Projekt zum ersten Mal eine vollwertige Alternative zur Pixel-Reihe, die bislang die einzige Basis für die offizielle Firmware war.

Diese strategische Öffnung hat mehrere Vorteile:

1. Weniger Abhängigkeit von Google:
   Google hat in den letzten Android-Versionen begonnen, die Entwicklung von Custom-ROMs aktiv zu erschweren. So fehlen bei Android 16 die bisher üblichen Device-Trees, vollständige Kernel-Commit-Historien und Treiberpakete. Für Projekte wie GrapheneOS, die sehr tief ins System eingreifen und Sicherheitsfeatures auf Kernel-Ebene implementieren, ist das ein massives Problem.
2. Stabilere Entwicklungsgrundlage:
   Wenn ein Hersteller offiziell mitarbeitet, bekommt das GrapheneOS-Team direkten Zugang zu allen notwendigen Ressourcen – ohne auf Googles Veröffentlichungsrhythmus oder Einschränkungen angewiesen zu sein.
3. Längere und planbarere Updatezyklen:
   GrapheneOS hat sehr hohe Anforderungen an Sicherheitspatches und Firmwarepflege. Ein kooperierender OEM kann diese Anforderungen gezielt berücksichtigen, anstatt dass sich die Entwickler mühsam an Googles Änderungen anpassen müssen.
4. Mehr Geräte, größere Reichweite:
   Der Pixel-Markt ist verhältnismäßig klein. Mit einem starken Partner kann GrapheneOS deutlich mehr Nutzer erreichen – und damit auch seine Bedeutung als sicherheitsfokussiertes Betriebssystem ausbauen.

Pixel-Support bleibt vorerst bestehen – aber die Prioritäten verschieben sich

Das Projekt bestätigte parallel, dass es weiterhin Unterstützung für die kommende Pixel 10-Serie geben wird. Allerdings ist die Anpassung an die neue Android-Version QPR1 deutlich aufwendiger als in den Vorjahren. Einen genauen Zeitplan für die Veröffentlichung gibt es deshalb nicht.

Langfristig ist aber klar erkennbar: Sobald das neue Partnergerät stabil läuft, wird GrapheneOS seine Entwicklung zunehmend auf diese Plattform fokussieren. Ob und in welchem Umfang neue Pixel-Modelle wie Pixel 11 noch unterstützt werden, ist offen.

Ein offizieller Release des neuen GrapheneOS-Smartphones wird nicht vor dem dritten Quartal 2026 erwartet. Das passt zum Zeitfenster, in dem Google traditionell neue Pixel-Geräte vorstellt.

Warum Google den Custom-ROM-Entwicklern das Leben schwer macht

Google veröffentlicht zwar weiterhin den Android-Quellcode über das Android Open Source Project (AOSP), aber entscheidende Bestandteile wie Gerätetrees, Treiberpakete und Kernel-Commit-Historien sind nicht mehr öffentlich verfügbar.

Das bedeutet:

• Ohne diese Komponenten ist die Entwicklung eines sauberen, stabilen Custom-ROMs deutlich schwieriger.
• Sicherheitskritische Teile des Systems lassen sich nicht mehr transparent prüfen oder nachbauen.
• Projekte wie LineageOS oder /e/OS müssen auf inoffizielle Quellen oder mühsame Reverse-Engineering-Prozesse zurückgreifen.

Für GrapheneOS, das besonders auf Integrität, reproduzierbare Builds und strenge Sicherheitsmaßnahmen setzt, war diese Entwicklung ein echter Bremsklotz. Die Partnerschaft mit einem Hersteller ist daher ein logischer und strategisch sinnvoller Ausweg.

Historische Parallele: OnePlus und CyanogenMod

Die Situation erinnert an die Zusammenarbeit zwischen OnePlus und CyanogenMod vor rund einem Jahrzehnt. Damals brachte OnePlus das OnePlus One direkt mit CyanogenMod auf den Markt. Auch dort profitierte ein Custom-ROM enorm von einer offiziellen Partnerschaft mit einem Hardwarehersteller.

Diese Kooperation endete zwar, als OnePlus auf OxygenOS umstieg, doch sie zeigte, wie stark ein Open-Source-Projekt durch direkten Hardwarezugang profitieren kann. GrapheneOS versucht nun, einen ähnlichen, aber stabileren und langfristigeren Weg zu gehen.

Fazit: Ein lang erwarteter Befreiungsschlag

Der geplante Wechsel von der Pixel-Exklusivität hin zu einer offiziellen Kooperation mit einem großen OEM ist ein Meilenstein für GrapheneOS. Er bedeutet:

• Mehr Unabhängigkeit von Google
• Längere Sicherheitsunterstützung und bessere Entwicklungsbedingungen
• Zugang zu moderner High-End-Hardware
• Potenziell größere Verbreitung und mehr Sichtbarkeit

Für sicherheitsbewusste Nutzer ist das eine sehr gute Nachricht: Statt sich auf Googles Launen verlassen zu müssen, steht künftig ein dediziertes High-Security-Smartphone zur Verfügung, das direkt auf GrapheneOS abgestimmt ist.

Wenn alles nach Plan läuft, könnte das Projekt damit endgültig den Sprung aus der Nische schaffen – und einen neuen Standard für sichere Android-Geräte setzen.

The post GrapheneOS bald für andere Smartphones? appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

• Nach einem großen Systemupdate muss man hier und da mal etwas nachjustieren.
• Manche Programme reagieren empfindlich auf Paketänderungen.
• Und unterschiedliche Distributionen bringen oft ihre eigenen kleinen Eigenheiten mit.

Für erfahrene Nutzer sind das Routineaufgaben. Für Einsteiger kann es jedoch unnötig abschrecken – obwohl Linux technisch meist nicht das Problem, sondern nur anders organisiert ist.

Genau hier will KDE Linux ansetzen – und das klassische Desktop-Linux radikal vereinfachen, ohne seine Offenheit und Flexibilität zu verlieren.

Ein Desktop, der wie aus einem Guss wirkt – KDE Plasma

Das Herzstück von KDE Linux ist KDE Plasma – eine der modernsten und beliebtesten Desktop-Oberflächen für Linux.

KDE Plasma bietet:

• Vertrautes Bedienkonzept: klassisches Startmenü, Taskleiste unten, Systemtray – ähnlich wie bei Windows.
• Umfangreiche Anpassbarkeit: Themes, Farben, Widgets, Panel-Positionen – alles lässt sich individuell gestalten.
• Hohe Performance: Läuft flüssig, auch auf älterer Hardware.
• Ein vollständiges Software-Ökosystem: Dolphin (Dateimanager), Gwenview (Bildbetrachter), Okular (PDF), Kate (Editor) und viele weitere Programme sind direkt integriert.

Typische Desktop-Elemente:

• Startmenü unten links
• Taskleiste mit offenen Programmen
• Systemtray (WLAN, Lautstärke, Uhrzeit, Benachrichtigungen)
• Virtuelle Desktops für mehr Übersicht
• Widgets für Wetter, Notizen oder Systeminfos

KDE Plasma ist seit Jahren für seine Kombination aus Eleganz, Leistung und Anpassbarkeit bekannt.
Mit KDE Linux bekommt es erstmals ein Betriebssystem, das genau auf diese Oberfläche zugeschnitten ist – nicht umgekehrt.

KDE Linux – ein anderer Ansatz für mehr Stabilität

Das eigentliche Revolutionäre an KDE Linux ist der Aufbau des Systems selbst.
Im Gegensatz zu klassischen Distributionen basiert es auf einem immutablen System. Das bedeutet:

👉 Das Basissystem ist schreibgeschützt – es kann nicht einfach „aus Versehen“ verändert oder beschädigt werden.
👉 Updates erfolgen atomar, also als Ganzes. Wenn etwas schiefgeht, wird einfach auf die vorherige Version zurückgerollt.
👉 Das System bleibt konsistent – ganz egal, wie viele Programme Ihr installiert oder wie lange Ihr es nutzt.

Praktischer Nutzen für Einsteiger:

• Keine Angst vor Updates, die irgendetwas zerschießen könnten.
• Keine inkonsistenten Paketversionen nach großen Systemupgrades.
• Ein sauberer, stabiler Unterbau, der einfach läuft.

Saubere Trennung: System und Anwendungen

KDE Linux trennt klar zwischen dem System und deinen Apps.
Programme werden nicht klassisch „ins System installiert“, sondern laufen isoliert in Containern (z. B. via Flatpak).

Das bringt gleich mehrere Vorteile:

• Programme bleiben funktionsfähig, unabhängig von Systemänderungen.
• Ihr bekommt neue Versionen von Apps schnell und einfach.
• Fehler in einer App beeinflussen nicht Euer ganzes System.

Das fühlt sich ähnlich an wie bei Smartphones oder Konsolen – ein stabiles Fundament mit flexibler App-Ebene.

Updates, die keinen Stress machen

Wer ein Smartphone oder Tablet nutzt, kennt das Prinzip:
Systemupdates laufen im Hintergrund – und entweder funktionieren sie oder sie werden automatisch rückgängig gemacht.

Genau das bringt KDE Linux auf den Desktop:

• Automatische, atomare Updates.
• Sofortige Rollbacks bei Problemen.
• Kein Chaos mehr nach großen Versionssprüngen.

Damit fällt einer der größten Stolpersteine für Linux-Einsteiger weg.

Eine klare Vision statt Distro-Dschungel

Viele Neulinge fragen sich:

„Welche Linux-Distro soll ich nehmen?“
„Ubuntu, Fedora, Manjaro oder Arch?“

KDE Linux macht Schluss mit dieser Zersplitterung.
Die KDE-Community liefert:

• eine klare Referenzplattform,
• einheitliche Benutzererfahrung,
• direkten Zugang zu den neuesten KDE-Technologien.

So müsst Ihr Euch nicht mehr durch Foren und Vergleichstabellen kämpfen – Ihr bekommt ein perfekt abgestimmtes Gesamtpaket.

Für Einsteiger ideal

KDE Linux richtet sich bewusst an Einsteiger, die weg von Windows wollen ohne sie einzuschränken:

• Wer einfach nur surfen, arbeiten oder Medien genießen will, bekommt ein stabiles, wartungsarmes System.
• Wer mehr möchte, kann Flatpaks, Themes, Tools und Widgets installieren – ohne das Basissystem anzufassen.
• Entwickler profitieren von einer standardisierten Plattform für Tests und Deployments.

Das ist nicht „Linux light“ – das ist Linux neu gedacht.

Nicht für jeden gedacht – Power-User haben andere Werkzeuge

Ein Punkt, den man bei all dem Lob für KDE Linux fairerweise erwähnen sollte:
Das System ist bewusst restriktiver aufgebaut als klassische Linux-Distributionen.

Weil das Basissystem unveränderbar (immutable) ist, können fortgeschrittene Nutzer:

• keine eigenen Systempakete installieren,
• keine tiefgehenden Änderungen an der Systemstruktur vornehmen,
• und nicht beliebig mit alternativen Paketquellen oder Kerneln experimentieren.

Das ist kein Bug, sondern Absicht: KDE Linux will eine zuverlässige, einheitliche Plattform für die große Mehrheit der Nutzer bieten – Menschen, die einfach ein stabiles, sicheres System möchten, das „einfach läuft“.

👉 Und genau diese Mehrheit macht realistisch rund 90 % der Linux-Anwender aus.
Die meisten Nutzer wollen:

• Surfen, Schreiben, Kommunizieren, Arbeiten, Spielen,
• einfache Updates,
• und sich nicht mit Paketabhängigkeiten oder Kernelmodulen beschäftigen müssen.

Für die verbleibenden Power-User oder Linux-Enthusiasten, die das System bis ins letzte Detail selbst gestalten wollen, gibt es natürlich weiterhin Alternativen.
Beispielsweise:

• KDE neon – sehr nah am KDE-Projekt, aber klassisch administrierbar.
• Arch Linux oder Fedora mit Plasma-Desktop für maximale Flexibilität.
• oder jede andere Distro, die vollständige Root-Freiheit bietet.

Damit wird klar: KDE Linux ersetzt nicht die Freiheit klassischer Distros – es ergänzt sie.
Power-User bekommen weiterhin volle Kontrolle, Einsteiger dagegen ein System, das sie nicht überfordert.

Noch Alpha – aber mit enormem Potenzial

Klar: KDE Linux befindet sich noch in der Alpha-Phase.
Nicht alles ist fertig – Secure Boot, erweiterte Partitionierung oder spezielle Hardwareunterstützung sind noch in Arbeit.
Aber das Konzept ist klar, durchdacht und vielversprechend.

Wenn das Projekt stabil wird, könnte es für Einsteiger die erste Linux-Distribution werden, die sich anfühlt wie ein Smartphone – nur mächtiger und freier, ohne Microsoft im Hintergrund die stündlich protokollieren wie Ihr Euren Rechner verwendet.

Fazit

KDE Linux ist kein weiteres „Bastelprojekt“, sondern eine klare Vision für ein modernes Desktop-Linux:

• stabile Basis durch immutables System
• Updates ohne Kopfschmerzen
• saubere Trennung von System & Apps
• einheitliche Benutzeroberfläche durch KDE Plasma
• einfacher Einstieg, starke Plattform

Für alle, die bisher gezögert haben, weil ihnen Linux „zu technisch“ erschien, könnte KDE Linux genau der Durchbruch sein, auf den viele gewartet haben.

👉 Ein Linux, das einfach funktioniert, aber offen und mächtig bleibt.
👉 Ein System, das Neulingen den Einstieg leicht macht – und Profis trotzdem nicht ausbremst.

The post KDE Linux – das neue Mint? appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

QR-Codes sind technisch gesehen nur eine Weiterentwicklung des klassischen Barcodes und keine inhärente Bedrohung. Der QR-Code (englisch Quick Response – „schnelle Antwort“) ist ein zweidimensionaler Code aus schwarzen und weißen Quadraten, der Daten speichert (iqual.chkrone.at). Im Prinzip funktioniert er wie der Strichcode auf Produktverpackungen im Supermarkt – nur dass ein QR-Code viel mehr Informationen fasst und speziell fürs Auslesen mit Kameras (z. B. im Smartphone) entwickelt wurde. Man kann also sagen: Ein QR-Code ist das Äquivalent des Barcodes für Smartphones.

Wie QR-Codes funktionieren

Ein QR-Code besteht aus einem Muster kleiner Quadrate, das von Scannern oder Smartphone-Kameras gelesen werden kann. Während herkömmliche Barcodes nur in einer Richtung Information durch unterschiedlich breite Striche codieren, nutzen QR-Codes eine zweidimensionale Matrix aus Pixeln. Dieses Design erlaubt es, deutlich mehr Daten auf kleinem Raum zu speichern – zum Beispiel Text, Webseiten-Adressen (URLs), Kontaktdaten (vCards), WLAN-Zugangsdaten oder andere kurze Informationen. Beim Scannen entschlüsselt die QR-Code-Software das Muster mithilfe eines Algorithmus und wandelt es zurück in lesbaren Text bzw. einen Link.

Besondere Muster im Code sorgen für schnelle Erkennbarkeit und Fehlertoleranz: Die drei markanten Quadrate in den Ecken eines QR-Codes dienen z. B. als Positionsmuster zur Orientierung für den Scanner. Zusätzlich enthält der Code Bereiche für Synchronisation und Fehlerkorrektur. Dank dieser Fehlerkorrektur können QR-Codes sogar dann noch gelesen werden, wenn Teile beschädigt oder verdeckt sind – ein Vorteil gegenüber einfachen Strichcodes. Das erklärt, warum man QR-Codes in der Praxis oft trotz Kratzern oder ungünstigen Winkeln noch scannen kann.

Zum Auslesen genügt heute meist ein Smartphone. Moderne Smartphones erkennen QR-Codes direkt über die eingebaute Kamera-App – man richtet die Kamera einfach auf den Code und erhält eine Meldung mit dem entschlüsselten Inhalt (z. B. eine URL zum Antippen). Alternativ gibt es spezialisierte QR-Scanner-Apps und sogar Online-Tools oder Browser-Erweiterungen, mit denen man einen QR-Code aus einem Bild heraus auslesen kann. In jedem Fall sollte die Scanner-App den gefundenen Text oder Link anzeigen, bevor man ihn öffnet. Gute Scanner bieten genau diese Vorschau an, sodass die Ziel-Internetadresse zunächst sichtbar ist und man den Vorgang abbrechen kann, falls einem die Adresse verdächtig vorkommt.

Nützliche Anwendungen im Alltag

QR-Codes sind heute äußerst praktisch und effizient, was ihren Siegeszug im Alltag erklärt (ncsc.admin.ch). Man begegnet ihnen in den unterschiedlichsten Bereichen: auf Plakaten, Flyern oder Produktverpackungen, wo sie als Brücke vom echten in das virtuelle Leben dienen. Statt eine lange Webadresse abzutippen, scannt man einfach den Code und gelangt in Sekundenschnelle zur gewünschten Webseite. Unternehmen nutzen das z. B. in der Werbung – ein Scan liefert mehr Infos zum Produkt oder führt direkt zur Bestellseite.

Tickets und Zugangskarten funktionieren inzwischen oft per QR-Code. Ob Bordkarte am Flughafen, Bahn- und Konzertticket oder der Impf- bzw. Testnachweis – all diese enthalten einen QR-Code, der beim Einlass oder Check-In einfach gescannt wird. Für Nutzer ist das bequem, und den Veranstaltern ermöglicht es eine schnelle, automatisierte Prüfung. Reisende können so ihre Tickets digital vorzeigen und verifizierentest.de, ohne Papier zu benötigen.

Bezahlen und Bankgeschäfte sind ein weiteres Feld: In der Schweiz findet man z. B. auf Rechnungen einen QR-Code (die QR-Rechnung), den man mit der Banking-App scannt, um alle Überweisungsdaten automatisch einzulesen – kein mühsames Eintippen von IBAN mehr. Ähnlich wird in anderen Ländern per QR-Code bezahlt, etwa mit Bezahldiensten oder Wallet-Apps im Laden. An Parkscheinautomaten kann man per QR-Code zu einer Bezahlseite gelangen (ncsc.admin.ch), und Restaurants bieten seit der Pandemie oft digitale Speisekarten via QR-Code an Tischaufstellern an. Selbst für den schnellen Austausch von Kontaktinfos oder WLAN-Zugang gibt es QR-Codes: So kann ein Visitenkartencode das lästige Abtippen ersparen, und ein WLAN-QR-Code loggt Gäste mit einem Scan ins Netzwerk ein. Kurzum – QR-Codes sind vielseitige Helfer, die Prozesse beschleunigen und Fehler vermeiden helfen.

Beispiel: Zwei Besucher scannen im J.N. “Ding” Darling National Wildlife Refuge (Florida) einen QR-Code mit dem Smartphone, um vor Ort mehr über die Natur zu erfahren (commons.wikimedia.org). QR-Codes auf Informationstafeln verbinden Ausflügler schnell mit weiterführenden Inhalten, ohne lange Links abtippen zu müssen.

Gefahren, Missbrauch und Verschwörungsmythen

Auch wenn QR-Codes uns den Alltag erleichtern, empfinden manche Menschen sie als unheimlich. Das liegt vor allem daran, dass wir mit bloßem Auge nicht erkennen können, was in einem QR-Code steckt. Wo ein normaler Text oder Link für uns lesbar wäre, sehen wir bei QR-Codes nur ein wirres Muster. Dieses Unwissen schafft Unsicherheit – und bietet Raum für wilde Spekulationen. So ranken sich tatsächlich einige Verschwörungstheorien um Strich- und QR-Codes . Manche selbsternannten „Aufklärer“ behaupten zum Beispiel, QR-Codes seien Werkzeuge einer totalen Überwachung oder ein Bestandteil finsterer Kontrollagenden. Besonders im Zusammenhang mit COVID-Impfzertifikaten und Einlass-Systemen wurde von solcher Seite suggeriert, hinter den Codes stecke ein Plan zur globalen Kontrolle.. Fakt ist jedoch: Ein QR-Code enthält meist nur einen Verweis – etwa auf eine Website oder auf einen verschlüsselten Datensatz – nicht die eigentliche persönliche Information selbst. Die Daten liegen auf dem Server, der durch den Code aufgerufen wird, und Zugriffe lassen sich dort normalerweise nachvollziehen. Mit anderen Worten: Ein QR-Code ist letztlich nur ein Träger von Informationen, kein geheimnisvolles Senderchen.

Andere krude Mythen behaupten gar, QR-Codes seien gesundheitsschädlich oder „strahlten etwas aus“. In esoterischen Kreisen gibt es z. B. Leute, die glauben, das Scannen von Strichcodes oder QR-Codes setze negative Energien oder gefährliche Strahlung frei – und sie versuchen dann, durch Durchstreichen oder Symbole die angebliche Strahlung zu „entstören“ (channelpartner.de). Dafür gibt es keinerlei wissenschaftlichen Beleg. Scanner lesen lediglich Hell-Dunkel-Kontraste – keine Frequenzen, keine Strahlen. Ebenso unbegründet sind Behauptungen, QR-Codes hätten irgendeinen satanischen Hintergrund oder gar außerirdischen Ursprung – all das entbehrt jeder Grundlage und entspringt einer übersteigerten Fantasie.

Ein besonders absurdes Beispiel kursierte während der Pandemie: Da wurde ernsthaft behauptet, geimpfte Menschen hätten unsichtbare QR-Codes unter der Haut und man könne diese per Smartphone auslesen (channelpartner.de). Ein im Netz verbreitetes „Beweisvideo“ dafür war natürlich eine plumpe Fälschung. QR-Codes bestehen aus gedruckten Kontrasten auf Oberflächen, nicht aus irgendwelchen versteckten Implantaten – man kann keinen QR-Code aus einem Arm herausleuchten, das ist technisch unmöglich (channelpartner.de). Solche Geschichten mögen spektakulär klingen, sind aber blanker Unsinn.

Missbrauch ist möglich – der Code an sich bleibt trotzdem neutral

Abgesehen von verrückten Mythen gibt es reale Gefahren im Umgang mit QR-Codes, über die man sachlich Bescheid wissen sollte. Wichtig ist dabei zu verstehen: Nicht der QR-Code selbst ist die Bedrohung, sondern was er beinhalten kann. Ein QR-Code kann zum Beispiel eine Webadresse enthalten – und wie jeder Link im Internet kann diese Adresse auf etwas Schädliches zeigen. Der Code an sich kann Eurem Smartphone keinen Schaden zufügen (test.de). Aber hinter einem QR-Code können sich eben auch Links zu betrügerischen Webseiten verstecken (test.de). Öffnet man eine solche Seite arglos, könnte sie versuchen, Schadsoftware (etwa einen Trojaner) aufs Gerät zu schleusen oder persönliche Daten abzugreifen (test.de). Kurz gesagt: QR-Codes haben keine inhärenten gefährlichen Eigenschaften – wohl aber können sie von Betrügern missbraucht werden, um Sie auf gefährliche Inhalte zu lotsen, genau wie ein manipulativer E-Mail-Link das könnte. Genauso wie ihr also auf gefälschte Email Links hereinfallen können, kann man also auch auf bösartiges Inhalte in QR Codes reinfallen.

Und tatsächlich nutzen Kriminelle diese Methode immer häufiger aus. Das Phänomen wird auch “Quishing” genannt – eine Wortmischung aus QR und Phishing. Betrüger erzeugen eigene QR-Codes, die auf ihre Fallen-Seiten führen, und platzieren sie dort, wo ahnungslose Nutzer sie scannen. Da immer mehr Menschen gegenüber dubiosen E-Mails misstrauisch geworden sind, weichen Betrüger auf QR-Codes aus, die z. B. im öffentlichen Raum aufgehängt oder aufgeklebt werden – das wirkt auf den ersten Blick vertrauenswürdiger (ncsc.admin.ch). Ein typisches Beispiel sind gefälschte QR-Codes an Parkautomaten: Hier kleben Täter einfach einen Aufkleber mit ihrem QR-Code über den echten Code der Parkuhr. Scannt ein Autofahrer diesen, landet er auf einer Phishing-Webseite, die täuschend echt vorgibt, eine Online-Bezahlseite für das Parkticket zu sein. Gibt man dort seine Kreditkartendaten ein, wird sofort ein hoher Betrag abgebucht – und da die echte Parkgebühr nie bezahlt wurde, bekommt man obendrein noch eine Strafgebühr wegen Falschparkens (ncsc.admin.ch). Solche Betrugsmaschen sind perfide, aber mit etwas Wachsamkeit durchschaubar und vermeidbar. In der Schweiz zum Beispiel würde Parkingpay niemals Kreditkartendaten abfragen! Im nächsten Abschnitt daher einige Tipps, wie man QR-Codes sicher nutzt.

Tipps für den sicheren Umgang mit QR-Codes

Wie gezeigt, liegt die potenzielle Gefahr bei QR-Codes in böswilligen Inhalten. Mit den folgenden einfachen Vorsichtsmaßnahmen Könnt Ihr diese Risiken minimieren, ohne auf die nützlichen Vorteile verzichten zu müssen:

• Unbekannte QR-Codes mit Vorsicht behandeln: Scannt nicht wahllos irgendwelche QR-Codes, deren Herkunft unklar ist – zum Beispiel wild im Stadtbild herumklebende Codes. Achtet darauf, ob ein Code vielleicht nur ein Sticker ist, der über einen offiziellen Code geklebt wurde (ncsc.admin.ch)(test.de). Im Zweifel lieber nicht scannen.
• Vorsicht bei QR-Codes auf unverlangt verteilten Flyern oder E-Mails: Wenn Euch auf der Straße Gratis-Gutscheine mit QR-Code in die Hand gedrückt werden oder Ihr per Mail/Chat einen QR-Code erhalten, den Ihr nicht erwartet habt, seid skeptisch. Solche Codes könnten auf Phishing-Seiten führen.
• Nutzt sichere Scanner mit Vorschau: Verwendet eine QR-Code-Scanner-App (oder die Smartphone-Kamera), die zuerst die entschlüsselte Webadresse anzeigt, bevor sie öffnet. So könnt Ihr das Ziel überprüfen. Erscheint eine kryptische Kurz-URL oder eine unbekannte Website, brecht einfach ab. Viele Smartphone-Kameras und gute Scanner-Apps machen dies ohnehin standardmäßig.
• Keine vertraulichen Daten preisgeben: Gebt niemals persönliche Daten, Passwörter oder Zahlungsinformationen auf einer Website ein, die Ihr über einen QR-Code erreicht habt, wenn Ihr der Seite nicht absolut vertraut (ncsc.admin.ch). Seriöse Anwendungen wie Banking nutzen QR-Codes nur zum Datentransport, nicht zum Abfragen sensibler Daten. Fordert eine Seite nach dem Scan z. B. Eure Login-Daten – Alarmzeichen!
• Apps nur aus vertrauenswürdigen Quellen installieren: Manche QR-Codes können auf App-Download-Seiten verweisen. Installiert Apps möglichst nur über offizielle App-Stores und nicht direkt von einer unbekannten QR-Code-Webseite. Andernfalls könntet Ihr Euch Schadsoftware einfangen. Im Zweifel sucht die App selbst im App Store, statt einem unbekannten QR-Link zu folgen.

Fazit

Befolgt man diese Tipps, ist das Risiko durch QR-Codes verschwindend gering. Millionenfach am Tag werden QR-Codes völlig problemlos genutzt – beim Bezahlen, beim Einchecken, beim Abrufen von Infos. Lasst Euch also nicht von unbegründeter Panikmache verunsichern: Ein QR-Code ist erstmal nichts weiter als ein moderner, Barcode. Er kann Euch das Leben vereinfachen, wenn Ihr ihn mit gesundem Menschenverstand einsetzt. Scannt bewusst und achtsam, wie Ihr auch auf einen Link im Internet nur mit Bedacht klicken würdet. Dann sind QR-Codes keine Bedrohung, sondern ein praktischer Helfer in unserer digital vernetzten Welt – schnell, effizient und an sich völlig harmlos.

The post Sind QR Codes wirklich böse appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Apps über die Weboberfläche

Nach dem Login als Admin klickt man oben rechts auf das Profilbild und wählt „Apps“ (in manchen Versionen heißt der Punkt „Apps & Integrationen“).
Links finden sich Kategorien wie Office, Sicherheit oder Multimedia. Mit einem Klick auf „Download und aktivieren“ wird die gewünschte App direkt aus dem offiziellen App-Store geladen und eingeschaltet.

Tipp: Manche Apps brauchen zusätzliche PHP-Module oder spezielle Servereinstellungen – diese Hinweise stehen in der jeweiligen App-Beschreibung und in der Administrationsübersicht:

Folgt den Dokumentationen der Hinweise zur Installation der zusätzlichen Servermodule oder fragt euren Managed Admin ob er dies für Euch tun kann.

Aktualisierungen einspielen

Updates werden in der App-Übersicht unter „Aktualisierungen“ angezeigt. Ein Klick auf „Aktualisieren“ reicht, um die neue Version einzuspielen. Meist ist kein Neustart notwendig:

Manchmal kann es bei der "Alle aktualisieren" Funktionen bei vielen Apps dazu führen, dass nicht alle Apps aktualisiert werden. Schaut später kurz nochmals vorbei und aktualisiert gegebenfalls die verbliebenen Apps manuell.

Apps deaktivieren

Nicht mehr benötigte Apps könnt ihr auch einfach nur deaktivieren, ohne sie zu installieren. Geht dazu auf Aktive Apps und deaktiviert einzelenen Apps mit dem Deaktivieren Button.

Umgekehrt könnt ihr sie auch wieder aktivieren, indem ihr auf die Liste der Deaktivierten Apps geht, und sie dort wieder aktiviert.

Für größere Installationen: Kommandozeile

Wer viele Instanzen verwaltet, spart Zeit mit dem OCC-Tool.

Alle Apps auf einmal aktualisieren:

sudo -u www-data php occ app:update --all

Einzelne Apps installieren:

sudo -u www-data php occ app:install

Nach dem Update

Kurz ins Admin-Log schauen (Einstellungen → Protokollierung), ob alles fehlerfrei lief. Bei größeren Versionssprüngen empfiehlt sich außerdem ein Backup vor dem Update.

Fazit

Mit diesen Schritten bleiben die Nextcloud-Apps immer aktuell – bequem über die Oberfläche oder automatisiert über die Kommandozeile.

Für weitere Nextcloudartikel, schaut unbedingt hier vorbei:

The post Nextcloud-Apps installieren und aktuell halten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Bedeutung von Werbeblockern

Werbeblocker sind ein zentrales Instrument für Sicherheit und Privatsphäre im Internet. Werbenetzwerke fungieren de facto als Datensammler: Sie analysieren Nutzerverhalten und erstellen umfangreiche Profile. Das Blockieren von Werbung schützt daher nicht nur vor aufdringlichen Anzeigen, sondern gilt als eine Form digitaler Selbstverteidigung. Zusätzlich sorgt es für ein schnelleres und ruhigeres Browsererlebnis.

Technische Grenzen und zusätzliche Erweiterungen

Die Blocking-API hat jedoch funktionale Beschränkungen. Einige Lösungen – etwa AdGuard für Safari oder Wipr – installieren deshalb ergänzende Erweiterungen. Diese haben Zugriff auf den gesamten Browserverlauf, um die Limitierungen der API zu umgehen. Wird die Zusatz-Erweiterung deaktiviert, sinkt die Blockierleistung spürbar.
Ob die Anbieter tatsächlich Daten sammeln, lässt sich von außen nicht belegen. Rein technisch besteht aber das Risiko, dass der Browserverlauf erfasst werden könnte – ein besonders schützenswerter Bereich für viele Anwender.

Vertrauensfragen bei den Anbietern

Die Auswahl eines Adblockers ist somit immer auch eine Frage des Vertrauens. Ein Beispiel: AdGuard liefert seit Jahren gute Ergebnisse und ist kostenlos, die Firmenstruktur sorgt jedoch regelmäßig für Diskussionen. Das ursprünglich russische Entwicklerteam hat seinen Geschäftssitz im Zuge der Sanktionen gegen Russland nach Zypern verlegt – ein Standort, der häufig als Sitz für Briefkastenfirmen dient. Diese Umstände sind kein Beweis für Fehlverhalten, erhöhen aber die Notwendigkeit einer kritischen Abwägung.

Marktübersicht: Vier etablierte Lösungen

Aktuell haben sich vier Safari-Adblocker als leistungsfähig etabliert:

1. uBlock Origin Lite
   • Nutzt nicht die Safari-Blocking-API, sondern Googles Manifest v3.
   • Entwickler gilt als vertrauenswürdig, der Funktionsumfang ist jedoch durch Manifest v3 eingeschränkt.
2. AdGuard
   • Kostenlose Lösung mit sehr guten Filterergebnissen.
   • Setzt für volle Funktionalität auf eine zusätzliche Erweiterung mit Zugriff auf den Browserverlauf.
   • Ob man dem Anbieter diese Berechtigung einräumt, muss individuell entschieden werden.
3. Wipr
   • Produkt eines unabhängigen Entwicklers.
   • Bietet eine schlanke, weitgehend wartungsfreie Lösung ohne komplexe Konfigurationsoptionen.
4. 1Blocker
   • Abo-Modell mit vergleichsweise hohem Preis.
   • Gilt als besonders effektiver Werbeblocker mit exzellenten Bewertungen.

Alle vier Lösungen setzen eine App-Installation voraus, die technisch den Browserverlauf mitschneiden könnte – auch wenn es dafür keine konkreten Belege gibt.

Ergänzende Schutzmaßnahmen

Mit Apps

Für weitergehenden Schutz lässt sich netzwerkweite Überwachung und Filterung durch Tools wie Little Snitch oder Little Snitch Mini einsetzen. Diese Programme können Tracking auch außerhalb des Browsers, also in anderen Apps, blockieren.

Via DNS

Werbung kann auch mit bestimmten DNS Servern verhindert werden, welche Werbe oder Tracking Domains per se blockiert, ohne dass man sich Extensions installiert. Dafür nimmt man sich eines der folgenden DNS Server die von Haus aus Werbung und Tracking herausfiltern:

Mullvad DoT- und DoH-Server mit Werbe- und Trackingfilter: IPv4: 194.242.2.3
IPv6: 2a07:e340::3 Servername für DNS-over-TLS: adblock.dns.mullvad.net
Adresse für DNS-over-HTTPS:  https://adblock.dns.mullvad.net/dns-query für iOS 14+: DoT-Server-Konfiguration (signiert, von Mullvad)

Mullvad DoT- und DoH-Server mit Werbe-, Tracking- und Malwarefilter: IPv4: 194.242.2.4
IPv6: 2a07:e340::4 Servername für DNS-over-TLS: base.dns.mullvad.net
Adresse für DNS-over-HTTPS:  https://base.dns.mullvad.net/dns-query für iOS 14+: DoT-Server-Konfiguration (signiert, von Mullvad)

Mullvad DoT- und DoH-Server mit Werbe-, Tracking-, Malware- und Socialmediafilter: IPv4: 194.242.2.5
IPv6: 2a07:e340::5 >Servername für DNS-over-TLS: extended.dns.mullvad.net
Adresse für DNS-over-HTTPS:  https://extended.dns.mullvad.net/dns-query für iOS 14+: DoT-Server-Konfiguration (signiert, von Mullvad)

Mullvad Server mit Werbe-, Tracking-, Malware-, Socialmedia-, Porno- und Gamblingfilter: IPv4: 194.242.2.9
IPv6: 2a07:e340::9 Servername für DNS-over-TLS: all.dns.mullvad.net
Adresse für DNS-over-HTTPS:  https://all.dns.mullvad.net/dns-query

DNS-Server auf dem Mac ändern

1. Systemeinstellungen öffnen
   Klicke oben links auf das Apple-Menü  → Systemeinstellungen (bzw. „Systemeinstellungen“ in älteren Versionen).
2. Netzwerk auswählen
   Wähle links in der Seitenleiste Netzwerk aus.
   Klicke beim gerade aktiven Anschluss (z. B. WLAN oder Ethernet) auf Details … bzw. Weitere Optionen ….
3. DNS konfigurieren
   Gehe zum Reiter DNS.
4. Einträge anpassen
   • Mit + fügst du neue DNS-Server hinzu (z. B. 1.1.1.1, 9.9.9.9).
   • Mit – entfernst du alte Einträge, falls gewünscht.
5. Übernehmen
   Klicke auf OK und dann auf Übernehmen, damit die neuen DNS-Server sofort aktiv werden.

Hinweise:

• Die Einstellung gilt nur für das jeweilige Netzwerkprofil (z. B. aktuelles WLAN oder Ethernet).
• Möchtet Ihr mehrere Netzwerke anpassen, wiederholt die Schritte pro Netzwerk.
• Bei Problemen könnt Ihr jederzeit über denselben Dialog die Option Standard wiederherstellen nutzen.

DNS Server auf iOS ändern

Hier eine kurze Schritt-für-Schritt-Anleitung, um auf iOS den DNS-Server zu ändern:

1. Einstellungen öffnen
   Tippt auf Einstellungen → WLAN.
2. Aktuelles WLAN auswählen
   Tippt auf das i-Symbol neben dem gerade verbundenen WLAN-Netzwerk.
3. DNS konfigurieren
   Scrollt zu DNS konfigurieren und tippt darauf.
   Wähle Manuell.
4. Alte Einträge löschen
   Tippe auf das – neben den bestehenden DNS-Adressen und entfernt sie.
5. Neue DNS-Server eintragen
   Tippe auf Server hinzufügen und gib die gewünschten DNS-Adressen ein.
6. Speichern
   Tippt oben rechts auf Sichern (bzw. Fertig).

Hinweis:
Bis heute erlaubt es Apple nicht, für seine iPhones die DNS Server Systemweit zu ändern (man möchte ja stets informiert sein, was die eigenen User im Netz so alles treiben). Die Einstellung gilt leider nur für dieses WLAN. Für jedes weitere Netzwerk müsst Ihr den DNS-Server separat anpassen. Mobile Daten (LTE/5G) lassen sich auf iOS nicht systemweit mit einem eigenen DNS konfigurieren – dafür wäre ein VPN notwendig.

Fazit

Trotz Apples Blocking-API bleibt die Wahl des Safari-Adblockers ein Balanceakt zwischen Funktionsumfang, Kosten und Vertrauen. Nutzer sollten nicht nur auf die Effektivität der Filter achten, sondern auch auf die jeweilige Datenzugriffsarchitektur und die Seriosität des Anbieters.

The post Safari-Adblocker im Vergleich: Funktionsweise, Risiken und Anbieter appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dieser Streit spiegelt sich auch in der Software-Wahl wider: Die allermeisten Bitcoin-Node-Betreiber verwenden die Referenzsoftware Bitcoin Core, während eine wachsende Minderheit auf die alternative Implementation Bitcoin Knots umsteigt. Beide Clients sind im Kern kompatibel, verfolgen aber unterschiedliche Philosophien im Umgang mit solchen „Spam“-Transaktionen. In diesem Artikel schauen wir uns Bitcoin Core vs. Bitcoin Knots genauer an – mit etwas Geschichte, den Unterschieden in der Mempool-Politik, warum Daten-Spam technisch überhaupt möglich ist, welche Vor- und Nachteile Filtermechanismen haben (Stichwort Lightning⚡) und wie letztlich die Transaktionsgebühren ein natürlicher Schutz gegen On-Chain-Spam bieten.

Was sind Bitcoin Core und Bitcoin Knots

Bitcoin Core ist die originale und meistgenutzte Bitcoin-Node-Software. Sie geht direkt auf Satoshi Nakamotos Ur-Client zurück und wird von einer großen Entwicklergemeinschaft gepflegt (thebitcoinway.com). Core setzt auf konservative Standards und Neutralität: Jeder gültige, regelkonforme Bitcoin-Transaction, die Gebühren zahlt, wird grundsätzlich akzeptiert und weiterverbreitet, ohne Bewertung ihres Inhalts.

Bitcoin Knots dagegen ist ein Fork (eine Abspaltung) von Bitcoin Core, der vom Entwickler Luke Dashjr betreut wird (reddit.com)(blog.bitfinex.com). Knots enthält fast den gesamten Code von Core, ergänzt aber einige erweiterte Einstellungen und strengere Richtlinien. Vor allem bietet Knots eingebaute Spam-Filter auf Mempool-Level – damit können Nodes z.B. Transaktionen aussortieren, die willentlich große Datenstücke ins Blockchain speichern (etwa via OP_RETURN) (blog.bitfinex.com). Knots gibt den Node-Betreibern also mehr Kontrolle, bestimmte „nicht-monetäre“ Transaktionen zu ignorieren, die sie für Verschwendung von Blockspace halten (blog.bitfinex.com). Außerdem aktiviert Knots standardmäßig Funktionen wie Replace-by-Fee (RBF) und andere Policy-Änderungen, die in Core teils nur optional sind (reddit.com).

Verbreitung: Bis vor kurzem war Knots ein Nischenclient – weniger als 5% der Nodes – doch 2025 ist seine Nutzung sprunghaft gestiegen (blog.bitfinex.com)(blog.bitfinex.com). Viele Umsteiger wollen ein Zeichen gegen „Datenmissbrauch“ setzen und sehen Knots als Möglichkeit, Bitcoin auf das Kerngeschäft „Peer-to-Peer Digital Cash“ zu fokussieren. Core-Befürworter hingegen pochen auf Offenheit und Kompatibilität – sie warnen davor, dass zu viele unterschiedliche Relay-Regeln das Netzwerk fragmentieren könnten. Wichtig zu betonen: Beide Programme folgen den gleichen Konsensregeln. Das heißt, ein Block der von einem Core-Knoten als gültig anerkannt wird, wird auch von einem Knots-Knoten anerkannt (und umgekehrt). Unterschiede bestehen nur in der Policy: also welche unbestätigten Transaktionen ein Node weiterleitet oder zurückweist. Diese feinen Unterschiede haben jedoch spürbare Auswirkungen für den Netzwerkbetrieb.

Unterschiedliche Mempool-Filter – was bedeutet das

Jede Bitcoin-Node verfügt über einen Mempool, eine lokale “Warteschlange” für unbestätigte Transaktionen. Wenn eine gültige Transaktion ins Netzwerk gesendet wird, landet sie in den Mempools der Nodes, wird von dort an weitere Nodes relayed, und wartet auf Aufnahme in einen Block durch Miner. Allerdings gelten für die Aufnahme in den Mempool sogenannte Standardness-Policies: Regeln, die über die reinen Konsensregeln hinausgehen. Diese Policies können z.B. Transaktionen ablehnen, die zwar gültig, aber ungewöhnlich sind – etwa extrem große Transaktionen, sehr viele Signaturen oder Ausgaben, die als „Daten-Träger“ dienen.

Bitcoin Core verwendet hier recht neutrale Standardeinstellungen. Zum Beispiel erlaubt Core standardmäßig eine OP_RETURN-Ausgabe (eine spezielle Transaktionsausgabe, die willkürliche Daten enthalten kann) von bis zu 83 Bytes (thebitcoinway.com)(thebitcoinway.com). Das reicht für kurze Nachrichten oder Verweise, ist aber absichtlich niedrig gehalten, um Missbrauch einzudämmen. Alles darüber hinaus würde Core nicht an andere Nodes weiterleiten. Core ist der Ansicht: Solange eine Transaktion gültig und gebührenzahlend ist, soll sie behandelt werden wie jede andere – das Netzwerk ist zensorfrei und anwendungsneutral (blog.bitfinex.com)(thebitcoinway.com). So sollen auch neue Nutzungsfälle experimentieren können, solange sie die Konsensregeln einhalten.

Bitcoin Knots hingegen verschärft einige dieser Standardregeln gleich ab Werk. Ein zentraler Unterschied: Knots stellt den datacarrier-Parameter, der OP_RETURN-Daten steuert, auf 0 (aus) (reddit.com). Das bedeutet, ein Knots-Knoten lehnt grundsätzlich jede Transaktion ab, die eine extra Daten-Ausgabe enthält (z.B. OP_RETURN), selbst wenn es nur ein paar Bytes Text sind. Solche TX gelangen dann nicht in seinen Mempool und werden nicht weitergeleitet. Darüber hinaus bietet Knots weitere Filtermöglichkeiten, etwa gegen bestimmte Protokolle wie Ordinals, Stamps, Runes (alles Methoden, NFTs oder Token-Daten in BTC-Transaktionen unterzubringen) oder sogar gegen Privacy-Transaktionen wie CoinJoins (blog.bitfinex.com)(blog.bitfinex.com). Die Philosophie dahinter: Bitcoin-Mempools sollen sauber bleiben, frei nach dem Motto “nur Geld, kein Unsinn”. Node-Betreiber können so ihren Ressourcenverbrauch senken (weniger Bandbreite/Plattenplatz für Spam) und ein Statement setzen, dass sie Bitcoin rein als Geldsystem sehen möchten (blog.bitfinex.com)(blog.bitfinex.com).

Diese unterschiedlichen Policies führen dazu, dass Bitcoin-Knoten nicht alle das gleiche Transaktionsset im Speicher haben. Ein konkretes Beispiel: Eine Ordinals-Transaktion, die ein Bild auf die Blockchain schreibt, hat oft eine große Witness-Datenmenge (mehrere Kilobyte). Bitcoin Core-Nodes würden sie in der Regel weiterleiten und minen, sofern die Gebühren bezahlt sind. Ein Bitcoin Knots-Node würde sie ablehnen (gar nicht erst in seinen Mempool nehmen oder weitergeben). Somit propagieren solche TX etwas langsamer oder über Umwege durchs Netzwerk – nämlich nur über die Core-Nodes. Hier stellt sich natürlich die Gretchenfrage: Kann man durch genügend Filterknoten diese “Spam”-Transaktionen ganz aus dem Netzwerk drängen? 🤔

Kann Bitcoin Knots „Datenmüll“-Transaktionen wirklich verhindern

Die kurze Antwort lautet: Nein, nicht wirklich. Zwar kann ein Knots-Knoten für sich beschließen, bestimmte TX als Spam nicht zu relayen – aber das verhindert nicht, dass diese letztlich doch in die Blockchain gelangen. Warum? Weil am Ende die Miner entscheiden, was in einen Block kommt. Und Miner sind in der Regel wirtschaftlich motiviert, nicht ideologisch. Sie nehmen die Transaktionen mit dem höchsten Gebührenertrag, egal ob darin ein Zahlungsauftrag oder ein JPEG steckt. Solange eine Transaktion den Konsensregeln entspricht und Gebühren zahlt, findet sich fast immer ein Miner, der sie aufnimmt. Viele Miner bieten inzwischen sogar direkte Kanäle (sogenannte “Transaction Submission” APIs) an, damit Kunden ihnen Transaktionen direkt einreichen können – vorbei an den öffentlichen Mempools (blog.bitfinex.com)(blog.bitfinex.com). Zum Beispiel hat der US-Miningpool Marathon mit “Slipstream” so einen Dienst geschaffen (blog.bitfinex.com). Fazit: Selbst wenn Eure eigene Node dank Knots bestimmte “Datenmüll”-TX nicht annimmt, können diese TX an anderen Stellen ins Netzwerk gelangen und gemined werden (blog.bitfinex.com). Sobald sie in einem gültigen Block enthalten sind, müssen auch Knots-Nodes den Block akzeptieren – die Daten sind dann unwiderruflich in der Blockchain und somit auch auf Ihrer Festplatte gespeichert (thebitcoinway.com).

Ein Reddit-Nutzer brachte es sehr treffend auf den Punkt: “Knots verhindert keinen Spam – du kannst deinen Mempool manipulieren wie du willst, aber die Miner werden trotzdem Transaktionen in Blöcke packen, wenn die Gebühren stimmen. Es ist ihnen egal, ob es Spam ist oder nicht. Am Ende erreicht dich der Spam sowieso, egal ob du Knots oder Core nutzt.” (reddit.com). Mit anderen Worten: Mempool-Filterung ist eher eine lokale Optik- und Effizienzmaßnahme, aber kein effektiver Netzwerkschutz. Jede Node speichert letztlich alle bestätigten Daten – ob man sie mag oder nicht, “like it or not” (thebitcoinway.com).

Allerdings argumentieren Knots-Befürworter, dass es trotzdem sinnvoll sei: Zum einen spare man lokal Ressourcen (kein Weiterleiten/Speichern bis zur Bestätigung). Zum anderen hofft man, dass wenn genug Knoten und vielleicht Miner filtern, “Spam”-Transaktionen unattraktiver werden. Tatsächlich gibt es mindestens einen kleinen Miningpool (Ocean), der Knots-Filter einsetzt und bewusst z.B. Ordinals-Daten nicht in seine Blöcke nimmt (blog.bitfinex.com). Dieser Pool wird u.a. von Luke Dashjr selbst mitbetrieben, aber er ist die Ausnahme – die meisten anderen Miner “lassen keine Satoshis liegen” und nehmen mit, was Geld bringt (blog.bitfinex.com). Somit bleibt Knots-Filterung vor allem ein symbolischer Protest gegen die „Datenflut“. Viele sehen darin eine Art „Votum mit den Füßen“: Node-Betreiber drücken aus, dass Bitcoin aus ihrer Sicht kein Allzweck-Datenspeicher sein sollte (blog.bitfinex.com)(blog.bitfinex.com). Aber faktisch aufhalten lässt sich eine motivierte Spam-Attacke damit nicht. Die ungeliebten Transaktionen fließen dann eben über die Nodes, die Core (ohne Filter) fahren, ins System und werden letztlich doch bestätigt (blog.bitfinex.com).

Warum ist Daten-Spam auf der Chain überhaupt möglich

Man könnte doch fragen: „Wenn die Bitcoin-Entwickler keine Bilder und Nachrichten auf der Blockchain wollen, wieso erlauben die Regeln sowas überhaupt?“ 🤷‍♀️ Die Wahrheit ist: Bitcoin war von Anfang an relativ offen gestaltet – es gibt Skriptbefehle und Funktionen, die missbraucht werden können, um beliebige Daten zu verewigen. Schon früh haben Leute kreative Wege gefunden, Botschaften in die Blockchain zu schreiben (sogar bevor OP_RETURN populär war, benutzte man z.B. sog. “bare multisig”-Outputs als Datenträger). Kuriositäten wie eine Heiratsantrag-Message oder die WikiLeaks-Nachricht 2016 wurden so ins Ledger gemeißelt (thebitcoinway.com)(thebitcoinway.com). Diese Gimmicks waren selten und klein (unter 80 Byte) – also kein echtes Problem.

Größere Spam-Wellen blieben lange aus, weil technische Limits und Kosten ein Hindernis waren. Beispielsweise wurde OP_RETURN 2014 eingeführt, aber mit striktem Limit (40 später 80 Bytes). Außerdem zählten solche Daten komplett zur 1 MB Blockgröße. Doch mit späteren Protokolländerungen hat Bitcoin ungewollt mehr Schlupflöcher für Datenspeicherung eröffnet:

• Segregated Witness (SegWit, 2017): Diese wichtige Skalierungs-Softfork lagerte Signaturdaten in einen separaten Blockteil (Witness-Bereich) aus und führte die Blockgewicht-Metrik ein. Dadurch wurde der effektive Block-Speicherplatz etwa auf 4 MB erweitert – zumindest für Witness-Daten (tokeninsight.com). Zudem erhalten Witness-Daten einen Rabatt bei der Gebührenberechnung (1 Byte Witness = 0,25 “Gewichtspunkte”). SegWit erhöhte also die Datenkapazität und senkte die Kosten pro Byte im Witness. Das heißt, wer kreative Hacks findet, um Nutzdaten in den Witness zu schmuggeln, kann viel mehr Informationen für viel weniger Gebühren unterbringen als vorher.
• Taproot (2021): Das Taproot-Upgrade brachte neue Skriptmöglichkeiten. Unter anderem vereinfacht es, große Datenblöcke im Witness unterzubringen, ohne an feste Limits zu stoßen (tokeninsight.com). Insbesondere erlaubt Taproot v1 „nicht-Standard“-Witness-Programme flexibler zu gestalten. Genau das nutzt die Ordinals-Methode aus: Durch einen Trick (einen OP_FALSE OP_IF … OP_ENDIF-Block im Skript) können beliebig große Daten ins Witness gepackt werden, ohne je ausgeführt zu werden (tokeninsight.com)(tokeninsight.com). So werden z.B. Bilddateien oder Texte als sogenannter Inscription in eine Taproot-Transaktion eingebettet. Praktisch ist die Grenze nur das Blockgewicht – theoretisch bis zu ~4 Millionen Bytes pro Block (4 MB) (tokeninsight.com). In der Praxis sind bisher Inscription-Größen von einigen Kilobyte bis ein paar hundert KB üblich, aber es wurde auch schon nahe ans Maximum gegangen. SegWit und Taproot haben diese Zweckentfremdung also erst ökonomisch rentabel gemacht (tokeninsight.com).
• Alternative Einbettungs-Tricks: Selbst wenn man OP_RETURN streng limitiert, fanden Nutzer Wege, Daten in anderen Strukturen zu verstecken. Beliebt war lange „bare multi-sig“: dabei legt man scheinbar einen Multi-Signatur-Output an, kodiert aber in den öffentlichen Schlüsseln die Payload-Daten – die Schlüssel selbst sind dann Dummy-Daten. Auch möglich: Viele winzige UTXOs mit bestimmten Mustern erzeugen (siehe das Phänomen BRC-20 Tokens 2023, wo Millionen minimaler Token-UTXOs entstanden (thebitcoinway.com)). Diese erhöhen sogar die UTXO-Datenbank für alle Nodes, was noch belastender ist als OP_RETURN (das per Flag als unspendable markiert und vom UTXO-Set ausgeschlossen wird) (thebitcoinway.com)(thebitcoinway.com). Mit anderen Worten: Versucht man eine Lücke zu schließen, weichen kreative Spammer eben auf eine andere aus. 🙃 Bitcoin ist ein permissionloses System – was nicht per Konsensregel verboten ist, das ist erlaubt. Und “wo ein Wille ist, ist auch ein Weg” – solange jemand bereit ist, Gebühren zu zahlen, kann er die Blockchain auch für Katzenbilder oder Liebesbriefe nutzen. Die Entwickler erkennen inzwischen selbst an: komplett verhindern ließe sich arbiträre Dateneinbettung nur durch eine Änderung der Konsensregeln, was jedoch einen hochumstrittenen Hardfork bedeuten würde (thebitcoinway.com). Daher geht der Trend eher dahin, Schadensbegrenzung zu betreiben (z.B. Daten ins OP_RETURN zu lenken, da diese Outputs prunebar sind und nicht die UTXO-Datenbank belasten (thebitcoinway.com)). Aber die Möglichkeiten werden denjenigen, die es wirklich darauf anlegen, kaum ausgehen.

Kurz gesagt: SegWit und Taproot haben Bitcoins Flexibilität und Kapazität erhöht – leider damit aber auch das Tor für mehr Daten-“Missbrauch” weiter geöffnet (tokeninsight.com). Dieses Zusammenspiel machte ab 2023 den massenhaften NFT-Spam auf Bitcoin (Ordinals, BRC-20 etc.) erst praktikabel. Die Community hat diese Nebenwirkung anfangs unterschätzt. Nun stehen wir vor der Frage: Akzeptieren wir Bitcoin als allgemeine “Immerwährende Datenbank”, oder halten wir strikt am Zahlungsnetzwerk-Charakter fest? Diese Kontroverse bildet den Kern von Core vs. Knots.

OP_RETURN – Schutzschild fürs UTXO-Set gegen Datenmüll

Damit jede Bitcoin-Node neue Transaktionen schnell prüfen kann, hält sie eine aktuelle „Bestandsliste“ aller noch nicht ausgegebenen Coins – das sogenannte UTXO-Set – permanent im Arbeitsspeicher. Je größer dieses Set wird, desto mehr RAM und Rechenleistung braucht eine Node, was den Betrieb verteuert und die Dezentralität schwächen kann.

Bevor 2014 OP_RETURN eingeführt wurde, versteckten manche Nutzer Daten in ganz normalen Ausgaben („bare multisig“). Solche Outputs sahen wie spendbare Coins aus und blieben daher dauerhaft im UTXO-Set, obwohl sie nur als Datenträger dienten. Das blähte die „Bestandsliste“ künstlich auf.

OP_RETURN löst genau dieses Problem: Ein Output mit diesem Skriptbefehl ist von vornherein nicht spendbar. Die Node weiß sofort, dass dieser Eintrag nicht ins UTXO-Set muss und kann ihn nach dem Empfang der Transaktion verwerfen. So bleibt das Set schlank, auch wenn Nutzer kleine Daten­schnipsel in die Blockchain schreiben.

OP_RETURN ist eigentlich als Schutzmechaismus eingeführt wurden – Daten dürfen weiterhin on-chain gespeichert werden, ohne dass das UTXO-Set durch Datenspam aufgebläht wird.

Nachteile der Mempool-Filterung – Lightning und andere Kollateralschäden

Die Idee, auf Node-Ebene bestimmte Transaktionen zu filtern, klingt für manche verlockend – doch sie hat Nebenwirkungen. Ein großes Problem: Wer definiert, was „Spam“ ist? Knots setzt hier harte Kriterien (z.B. “alles über 0 Byte OP_RETURN ist Spam”). Aber es gibt legitime Anwendungsfälle, die von solchen Regeln getroffen werden könnten.

Beispiel: Einige Privacy-Protokolle wie BIP47 PayNyms oder Samourai Whirlpool nutzen kleine OP_RETURN-Felder, um Nutzern zu helfen, sich abzustimmen oder Zahlungsinfos privat zu übermitteln (thebitcoinway.com).

Ein Knots-Knoten würde solche Transaktionen pauschal wegfiltern, obwohl sie aus Nutzersicht sinnvoll und legitim sind (sie verletzen keine Konsensregeln, zahlen Gebühren und dienen der Privatsphäre). Tatsächlich kam es 2023 zum Eklat, als ein von Luke Dashjr betriebener Filter-Miningpool began, Whirlpool-CoinJoins wegen eines 46-Byte-OP_RETURN nicht mehr zu minen (blog.bitfinex.com). Die Privacy-Community war empört und sah darin Zensur legitimer Zahlungen, während Luke das als notwendigen Anti-Spam-Schritt verteidigte (blog.bitfinex.com). Dieser Vorfall zeigt: Filter können Fehlalarm schlagen und wichtige Funktionen beeinträchtigen, die man gar nicht als Spam einstufen würde – je nach Perspektive.

Noch gravierender könnten Filter auf Lightning-Netzwerk-Transaktionen wirken. Das Lightning Network ist ein Second-Layer fürs schnelle Bezahlen, der aber im Ernstfall auf On-Chain-Transaktionen zurückgreift (z.B. beim Öffnen/Schließen von Kanälen oder beim Schlichten von Betrugsversuchen). Lightning-Transaktionen sind zwar normale Bitcoin-Transaktionen, enthalten aber teils ungewöhnliche Outputs. Speziell seit Einführung der Anchor Outputs (kleine „Anker“-Outputs von 330 Satoshi) nutzen LN-Commitment-Transaktionen absichtlich winzige Ausgabebeträge, um später eine Child-Pays-for-Parent (CPFP)-Fee-Erhöhung zu ermöglichen (lightspark.com)(lightspark.com). Aus Sicht der standard Policy sind solche Miniausgaben Dust und würden eigentlich nicht relayed – das Lightning-Protokoll brauchte hier also explizite Anpassungen im Bitcoin-Core-Mempoolcode, um zuverlässig zu funktionieren (bitcoin.stackexchange.com)(bitcoin.stackexchange.com). So wurde kürzlich eine “Ephemeral Anchors” Policy eingeführt, die es erlaubt, ein 0-Sat-Output mit 0 Fee zu propagieren, solange es sofort per Kindtransaktion mit Fee ausgeglichen wird (bitcoin.stackexchange.com)(bitcoin.stackexchange.com). Dieser Kniff war nötig, weil zuvor ein LN-Knoten unter Umständen seine eigene (zu niedrig bepreiste) Kanal-Closing-Transaktion nicht ins Netzwerk bekam, wenn die Fees plötzlich anzogen – selbst CPFP half nicht immer, da die Eltern-Transaktion alleine vom Mempool zurückgewiesen wurde (bitcoin.stackexchange.com). Mit Package Relay (Paket-Weiterleitung) wurde dieses Problem entschärft: Node akzeptieren jetzt 2-Transaktionen-Pakete (Eltern+Kind) gemeinsam, falls ihre kombinierte Fee ausreicht (bitcoin.stackexchange.com)(bitcoin.stackexchange.com).

Warum dieser technische Exkurs? Er zeigt: Lightning ist auf verlässliche Relay-Regeln angewiesen. Zu strikte oder inkonsistente Filterpolitik kann die Funktionalität von Second-Layer-Lösungen beeinträchtigen. Wenn z.B. ein Teil des Netzwerks bestimmte LN-Transaktionen fälschlich als Spam behandeln würde, könnten Lightning-Nutzer im Extremfall Probleme bekommen, ihre Kanäle rechtzeitig zu schließen oder die richtige Fee durchzusetzen – was Sicherheitsrisiken birgt. Glücklicherweise sind Core-Entwickler eng am Ball, um das zu verhindern. Aber bei alternativen Implementationen wie Knots muss man sich fragen: Werden dort all diese feinen Ausnahmen mitgetragen? Oder könnte es sein, dass ein Knots-Node im Eifer des Spam-Filterns mal eine Lightning-Transaktion nicht weiterleitet, weil sie z.B. einen ungewöhnlichen Output enthält? Diese Gefahr ist zumindest denkbar, wenn Filterregeln eigenmächtig verändert werden.

Zusammengefasst: Mempool-Filterung schafft Uneinheitlichkeit, was für ein globales Netzwerk immer heikel ist. Unterschiedliche Sichtweisen der Nodes auf “was erlaubt ist” können im schlimmsten Fall zu Split-Brain-Szenarien führen, wo ein Teil des Netzwerks Transaktionen “A” nicht kennt, die der andere Teil aber schon kennt und vielleicht mined. Aktuell ist das kein dramatisches Problem (die meisten folgen Core-Policy, Knots ist noch in der Minderheit), aber je mehr Nodes abweichende Filter fahren, desto mehr könnten sich Relay-Inseln bilden. Außerdem entgeht dem Netzwerk als Ganzes durch herausgefilterte Transaktionen auch ein Teil der Fee-Einnahmen – was ironischerweise langfristig schlecht für die Sicherheit sein könnte (blog.bitfinex.com). Denn Bitcoin ist darauf angewiesen, dass in Zukunft Transaktionsgebühren den Minern genug Anreiz bieten, weiter zu schürfen (wenn die Block-Subsidy immer kleiner wird). Wenn man also valide, zahlungsbereite Transaktionen unterdrückt – seien es NFTs, CoinJoins oder andere – verzichtet man auch auf Gebühren, die sonst zur Absicherung des Netzwerks beigetragen hätten (blog.bitfinex.com). Man schneidet sich möglicherweise ins eigene Fleisch, um ideologische Reinheit zu wahren.

Knots - Single Point of Failure Risko

Wenn man sich bei einer Software auf eine einzige Person als Hauptentwickler verlassen muss, spielen deren Sicherheits­praxis und bisherige Historie eine große Rolle. Im Fall von Bitcoin Knots ist das Luke Dashjr. Zu öffentlich bekannten Vorfällen bei ihm gehören unter anderem:

• Kompromittierter Signierschlüssel – ein Schlüssel, mit dem offiziell neue Versionen signiert werden, wurde einmal kompromittiert.
• Großer Diebstahl seiner eigenen Coins – Luke verlor eine sehr große Menge Bitcoin (ca. 200), weil die Coins auf einem Server lagen, der erfolgreich angegriffen wurde. Anschliessend verwendete er den Server weiter, bereinigte diesen von der Schadsoftware und setzte diesen nicht mal neu auf.

Diese Ereignisse bedeuten nicht, dass Luke in böser Absicht gehandelt hätte. Aber sie zeigen Schwächen in Prozess- und Schlüsselmanagement, die gerade dann relevant sind, wenn genau diese Person der alleinige „Gatekeeper“ für einen Node-Client ist.
Die naheliegende Frage: Wenn jemand seine eigenen über 200 Bitcoin nicht in einer Hardware-Wallet abgesichert hat – also eine Entscheidung, die für das eigene Leben finanziell extrem wichtig ist – warum sollte man dann blind darauf vertrauen, dass dieselbe Person beim Betrieb der eigenen Node stets perfekte Sicherheitsprozesse einhält?

Im Bitcoin-Ökosystem stützt sich die Integrität von Software-Releases auf sorgfältiges Schlüssel-Handling, reproduzierbare Builds und die gemeinsame Überprüfung durch die Community. Wird der Maintainer-Key kompromittiert, gerät genau der Mechanismus ins Wanken, auf den sich die Nutzer verlassen, um sicherzugehen, dass sie auch wirklich die Version ausführen, die sie zu installieren glauben.

Es geht hier nicht um einen persönlichen Angriff, sondern um eine Risikoabwägung:
Wer Knots einsetzt, ohne selbst sehr gründlich zu verifizieren, bündelt viel Vertrauen in sehr wenige Hände – und genau das ist in einem dezentralen System wie Bitcoin immer ein potenzieller Schwachpunkt.

Gebühren – der natürliche Schutzmechanismus gegen Spam

Gibt es abseits von Filtern und Regelwerken überhaupt einen Schutz gegen Spam auf Bitcoin? Ja – die Transaktionsgebühren! Bitcoins ökonomisches Design bringt automatisch eine Spam-Bremse mit sich: Jede Transaktion kostet Gebühren, und zwar umso mehr, je größer (datenlastiger) sie ist. Spammer zahlen also drauf. Will jemand z.B. 100 KB an Bilddaten ins Ledger schreiben, muss er entsprechend hohe Fees anbieten, um gegen normale Transaktionen zu konkurrieren (denn Miner priorisieren nach Gebührenrate). In Zeiten voller Blöcke wird das sehr teuer, sodass Spam finanziell unattraktiv wird (thebitcoinway.com).

Gebühren dienen somit als Marktmechanismus, der sicherstellt, dass Blockspace meist an die wirtschaftlich wichtigsten Transaktionen geht – alles andere wird herausgedrängt, außer der Spammer ist bereit, ein kleines Vermögen zu verbrennen (swissmoney.com). Wie bei E-Mail-Spam, wo Portokosten Spam verhindern würden, sorgt das Gebührenmodell dafür, dass man das Netzwerk nicht beliebig mit Nonsens fluten kann (swissmoney.com).

Bitcoin-Core-Entwickler argumentieren deshalb: Wenn eine Transaktion alle Konsensregeln einhält und die nötige Fee zahlt, dann ist sie per Definition kein Spam (thebitcoinway.com) – denn sie leistet ihren „Beitrag“ und verdrängt niemanden, der nicht mitbieten könnte. Sollte der Blockplatz durch unsinnige Daten belegt werden, werden echte Nutzer eben höhere Gebühren bieten, bis sich ein neues Gleichgewicht findet.

Diese Marktdynamik hat man 2017 bereits bei den Blocksize Wars gesehen: Blockspace ist ein begrenztes Gut, und Gebühren sind das Zuteilungsinstrument. Somit sind Transaktionsgebühren ein natürlicher Spam-Filter: Sie „stellen sicher, dass nur seriöse Transaktionen verarbeitet werden“, wie ein Guide es ausdrückt (swissmoney.com). Man könnte sagen: Wer für 4 MB Bilddaten pro Block dauerhaft zahlt, der subventioniert halt das Mining – und wenn es ihm das Wert ist, sei es drum. Sobald jedoch die Nachfrage für echte Finanztransfers steigt, werden solche Spielereien von selbst zurückgehen, da sie unerschwinglich werden.

Ein weiterer limitierender Faktor ist die Blockgrößenbegrenzung. Auch wenn durch SegWit/Taproot mehr Daten reinpassen, bleibt pro Block ein Hardlimit (~4 Mio Weight Units). Niemand kann das Netzwerk mit endlosen Daten zuspammen – pro 10 Minuten ist physisch Schluss. In dieser Zeit konkurrieren alle Transaktionen um den knappen Platz. Und genau hier greift wieder der Gebühren-Mechanismus: Unsinn landet nur drin, wenn kein sinnvollerer Nutzen diesen Platz haben wollte oder der Unsinnige mehr bezahlt als alle anderen. In beiden Fällen entsteht keine gratis Überflutung, sondern immer ein hoher Preis.

Fazit – Bitcoin zwischen Neutralität und Zweckbindung

Die Diskussion Bitcoin Core vs. Bitcoin Knots zeigt, wie unterschiedlich die Sichtweisen auf Bitcoin sein können. Die eine Seite (Core) betont Offenheit und Neutralität: Bitcoin ist ein neutrales Protokoll, das nicht zwischen “guten” und “schlechten” Transaktionen unterscheidet, solange sie den Regeln folgen und Gebühren zahlen (blog.bitfinex.com)(thebitcoinway.com). Dieses Lager sieht Filter eher kritisch und verweist auf Marktmechanismen und Protokoll-Weiterentwicklungen, um mit Missbrauch umzugehen. Die andere Seite (Knots) betont Reinheit und Effizienz: Bitcoin soll primär ein Wertübertragungsnetzwerk bleiben, kein “Datenmüllplatz”. Sie sind bereit, auf Node-Ebene einzugreifen, um die ihrer Meinung nach ursprüngliche Vision (Bitcoin als Geld) zu verteidigen – notfalls auch mit harten Filterschemen, die technisch an Zensur grenzen (blog.bitfinex.com)(thebitcoinway.com). Beide Gruppen wollen letztlich Bitcoin schützen, nur auf unterschiedliche Weise: durch Maximierung der Freiheit vs. Wahrung eines Zwecks.

Für normale Bitcoin- und Lightning-Nutzer ändert sich durch diesen “Node War” unmittelbar wenig. Es besteht keine Gefahr für Eure Coins – egal ob die Node-Mehrheit Core oder Knots nutzt, die Konsensregeln bleiben gleich und Ihre Transaktionen werden bestätigt (vorausgesetzt, Ihr zahlt ausreichende Gebühren). Allerdings lohnt es sich, die Debatte zu verfolgen, denn sie könnte langfristig beeinflussen, wie sich Bitcoin weiterentwickelt. Im schlimmsten Fall könnten extreme Unstimmigkeiten sogar zu Protokolländerungen oder Abspaltungen führen, aber soweit ist es (noch) nicht – bislang handelt es sich um eine Policy-Differenz, die jeder Node-Betreiber für sich entscheiden kann.

Interessant ist, dass die Knots-Welle auch positive Effekte haben kann: Mehr Vielfalt bei den Node-Implementierungen könnte die Dominanz von Core verringern und das Netzwerk dezentraler und resilienter machen (blog.bitfinex.com). Solange die Konsensbasis gleich bleibt, ist ein gewisses Maß an Wettbewerb vielleicht gesund. Letztlich erinnert die Situation an die Blocksize-Debatte 2017: unterschiedliche Visionen prallen aufeinander, und durch aktives “Mitstimmen” der Nutzer (in dem Fall via Node-Auswahl) wird sich zeigen, wohin die Reise geht (blog.bitfinex.com)(blog.bitfinex.com). Bitcoin hat schon oft bewiesen, dass es in solchen Diskursen am Ende gestärkt hervorgehen kann.

Zusammengefasst: Bitcoin Core und Bitcoin Knots stehen stellvertretend für zwei Philosophien – Neutralität vs. Selektivität. Daten-Spam auf der Blockchain ist technisch möglich geworden (SegWit/Taproot), aber die Gebühren sorgen dafür, dass er nie überhandnimmt. Node-Filter wie in Knots können im kleinen Rahmen ein Zeichen setzen und lokalen Traffic verringern, doch sie sind kein Allheilmittel und bringen Trade-offs (von verpassten legitimen TX bis hin zu komplexerer Netzwerktopologie). Ob Bitcoin am Ende eher dem “Code is law”-Prinzip (jede gültige TX ist willkommen) folgt oder sich stärker als zweckgebundenes Finanzsystem definiert, wird die Zukunft zeigen. Für technisch interessierte Laien gilt jedenfalls: Man muss nicht in Panik verfallen (thebitcoinway.com). Eure selbst verwalteten Bitcoins sind sicher, egal ob gerade JPEGs oder andere Daten über die Chain gejagt werden. Die Blockchain ist groß genug für allerlei Kuriositäten – und mit Lightning haben wir ja zum Glück einen Weg, die wichtigen Zahlungen schnell und kostengünstig off-chain abzuwickeln, weitgehend unbehelligt vom Treiben auf der Base-Layer. In diesem Sinne: Keep calm and HODL on! 🧘‍♂️

The post Bitcoin Knots vs. Bitcoin Core – Unterschiede erklärt appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Warum Nextcloud News

RSS-Feeds sind ein bewährtes Mittel, um Inhalte von Webseiten – etwa Nachrichtenportalen, Blogs oder Podcasts – automatisch zu beziehen. Mit Nextcloud News hollt Ihr Euch diese Funktion direkt in Eure private Cloud. Dadurch entfällt die Nutzung externer Anbieter, die in puncto Datenschutz oft schlechter aufgestellt sind. Da es sich um freie Open-Source-Software handelt, gibt es weder Werbung noch kostenpflichtige Zusatzfunktionen.

Die App ist sowohl am Desktop als auch auf Smartphones nutzbar. Für Android findet Ihr sie im Google Play Store sowie bei F-Droid, die iOS-Variante ist im Apple App Store erhältlich.

Welche Möglichkeiten bietet Nextcloud News

Die News-App kombiniert einfache Bedienung mit allen Funktionen, die man von einem modernen RSS-Reader erwartet. Zu den wichtigsten Merkmalen zählen:

• Zentrale Verwaltung von Feeds: RSS-Quellen lassen sich direkt im Nextcloud-Interface hinzufügen und organisieren – so bleibt der Überblick jederzeit gewahrt.
• Automatische Aktualisierung: Neue Artikel erscheinen sofort in der Übersicht. Auf Wunsch könnt Ihr Euch benachrichtigen lassen, sobald frische Inhalte vorliegen.
• Starker Datenschutz: Anders als bei externen Diensten werden keinerlei Daten an Dritte weitergegeben. Außerdem greift die App auf die Sicherheitsfunktionen der Nextcloud-Instanz zurück.

Nextcloud News Installation für die eigene Instanz

Wer eine eigene Nextcloud hostet, kann die App ganz einfach im Appstore der Nextcloud installieren:

Ein Konfiguration ist in dem Sinne nicht nötig, die App funktioniert out-of-the-box. Ihr benötigt zur Nutzung einfach einen Client.

Nutzung von Nextcloud News

In der Nextcloud-Oberfläche findet Ihr nach der Installation die App „News“ im oberen Menü.
Dort könnt Ihr:

• Über das „+ Abonnieren“-Symbol neue RSS-Feeds hinzufügen (einfach die Feed-URL einfügen und in eine Kategorie einordnen falls erwünscht).
• Eure Feeds anschliessend in Ordnern organisieren und kategorisieren, um sie übersichtlich zu halten.
• In der Hauptansicht die neuesten Artikel lesen, durchsuchen oder als gelesen markieren.
• Über die Administratoren-Einstellungen könnt Ihr festlegen, wie oft Feeds automatisch aktualisiert werden. In den App-Einstellungen könnt Ihr Feed Listen importieren oder exportieren oder die Ansicht anpassen.

So habt Ihr Eure Nachrichten, Blogs oder Podcasts direkt in der Nextcloud griffbereit – egal ob am PC oder über die mobile App.

Welche Clients sind kompatibel mit Nextcloud News

Die REST-API gestattet es nun Euch, die News-App mit einer breiten Palette an Sync-Clients zu verbinden, um RSS-Clients zu synchronisieren. Darüber hinaus besteht über die Schnittstelle auch die Möglichkeit, eigene Anwendungen zu integrieren. Nextcloud News lässt sich mit folgenden Clients verbinden:

Empfehlung für Android Client: Feedrops

Mit der Android App Feedrops könnt Ihr Euch ganz einfach mit der Nextcloud verbinden. Ladet Euch die App von F-Droid, oder einem Appstore Eurer Wahl herunter und installiert sie auf Eurem Smartphone. Beim starten der App werdet ihr gleich gefragt, ob Ihr ein lokales Konto erstellen wollt, oder ob Ihr Euch mit einem externen Konto verbinden wollt. Ihr nehmen wir natürlich Nextcloud News.

Meldet Euch normal mit eurem Nextcloud Username und Passwort an, und nehmt als Account URL die Adresse Eurer Nextcloud Instanz. Falls Ihr unser gratis Nextcloud verwendet, erstellt bitte in den Sicherheitseinstellungen ein App-Password, und verwendet dieses, anstelle Eures yourdevice Kontos.

Die Anwendung der Apps ist relativ simpel und selbsterklärend. Ihr habt nun Eure Feeds, die Ihr in der Nextcloud abonniert habt, automatisch auch auf Eurem Smartphone. Abonniert Ihr neue Feeds, werden die automatisch mit der Nextcloud synchronisiert, und steht dann mit anderen verbundenen Geräten zur Verfügung.

Empfehlung für Linux Client: Fluent Reader oder Newsflash

Beides sind gute RSS Reader, Fluentreader kommt jedoch ohne Ordner Unterstützung, ihr müsst die Feeds teilweise manuell in die entsprechenden Ordner schieben, bei Newsflash geschieht dass automatisch. Newsflash könnt ihr Euch schnell und einfach via Flatpak inststallieren:

https://flathub.org/apps/io.gitlab.news_flash.NewsFlash

Bei der Einrichtung werdet Ihr wie Readrops gefragt, was für ein Konto Ihr erstellen wollt. Nehmt hier natürlich auch Nextcloud News:

Loggt Euch anschliessend mit euren Nextcloud Credentials ein:

Danach befindet Ihr euch auf der Oberfläche von Newsflash. Rechts findet Ihr eure Ordner mit den Abos, in der Mitte den jeweiligen Newsfeed, und ganz rechts den Artikel selber. Die Ansicht kann natürlich in den Einstellungen angepasst werden. Auch hier werden Eure Änderungen direkt auf die Nextcloud gepusht. Ändert Ihr in Newsflash etwas, abonniert einen neuen Kanal, oder löscht Kanäle, werden sie auch auf dem Nextcloud Server gelöscht, was wiederrum heisst, dass die Änderungen auch auf die anderen Geräte übertragen werden. Eine Feine Sache um seine Feeds überall bereit zu haben.

Fazit

Die Synchronisierung von Feeds mit Nextcloud News ist zuverlässig und komfortabel. Alle abonnierten Inhalte werden automatisch im Hintergrund aktualisiert und stehen so auf jedem Gerät, ob Desktop oder Smartphone, stets in gleicher Form bereit. Dank der REST-API lassen sich verschiedene Clients anbinden, sodass Artikel überall synchron gelesen oder als erledigt markiert werden können. Damit bietet Nextcloud News eine nahtlose und datenschutzfreundliche Lösung, um RSS-Feeds zentral zu verwalten. Datenschutz kann auch einfach gehen!

The post RSS Feeds über Nextcloud synchronisieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was sich geändert hat

Mit der Veröffentlichung des Quellcodes von Android 16 hat Google erstmals auf wichtige Komponenten verzichtet:

• Keine Device-Trees für Pixel-Geräte
• Keine Treiber-Binärdateien (Blobs)
• Kernel-Source nur mit eingeschränkter Commit-Historie

Bisher war es üblich, dass Google diese Daten zusammen mit dem AOSP-Quellcode veröffentlichte, wodurch Pixel-Geräte zu den „Referenzmodellen“ für Custom-ROMs wurden.

Warum sorgt das für Aufsehen

Bislang hat Google der Community mit den Device-Trees, Treibern und Kernel-Quellen eine Art „Bauanleitung“ für Pixel-Smartphones mitgegeben. Entwickler konnten diese Daten nehmen, anpassen und relativ einfach eine neue Android-Version als Custom-ROM zum Laufen bringen.

Jetzt fehlen diese offiziellen Grundlagen. Das heißt:

• Alte Device-Trees aus Android 15 übernehmen: Entwickler müssen versuchen, die Baupläne der Vorgängerversion weiterzuverwenden. Das ist aber fehleranfällig, weil sich bei jeder neuen Android-Version intern viel verändert. Alte Baupläne passen oft nicht mehr zu den neuen Strukturen.
• Binärdateien per Reverse Engineering analysieren: Viele Funktionen in Smartphones – Kamera, Fingerabdrucksensor, Funkmodul – hängen von proprietären Treibern ab, die Google bisher veröffentlicht hat. Ohne diese Treiber bleibt nur der umständliche Weg, die fertigen Dateien zu zerlegen und zu untersuchen, um herauszufinden, wie man sie unter Android 16 überhaupt nutzen kann.
• Eigene Device-Trees von Grund auf erstellen: Wenn beides nicht funktioniert, müssen Entwickler komplett neue Baupläne selbst schreiben – praktisch ein Nachbau der gesamten Gerätebeschreibung, ohne dass der Hersteller ihnen sagt, wie das Gerät genau arbeitet. Das ist extrem zeitaufwendig und erfordert tiefes Expertenwissen.

Für die Community bedeutet das:

• Mehr Aufwand – was früher Wochen dauerte, kann nun Monate verschlingen.
• Mehr Verzögerungen – neue Android-Versionen erscheinen später als Custom-ROM.
• Höhere Einstiegshürden – neue Entwickler, die sich in die Szene einarbeiten wollen, werden schneller abgeschreckt, weil der Einstieg ohne offizielle Hilfen kaum machbar ist.

Kurz gesagt: Google hat die Spielregeln geändert. Anstatt den Entwicklern den Schlüssel in die Hand zu geben, müssen sie sich nun durchs Kellerfenster zwängen.ler.

AOSP bleibt bestehen – aber mit verändertem Fokus

Google hat Spekulationen über ein mögliches Ende des Android Open Source Project (AOSP) sofort dementiert. Seang Chau, Vice President und General Manager der Android-Plattform, stellte auf X klar: „AOSP wird NICHT verschwinden.“

Stattdessen sieht Google künftig Cuttlefish, ein virtuelles Android-Referenzgerät, als Standard für AOSP. Für Entwickler heißt das: weniger Abhängigkeit von realer Hardware, aber auch weniger Transparenz für Geräte wie die Pixel-Serie.

Zwischen den Zeilen: Soll Custom-ROM-Entwicklung erschwert werden?

Offiziell begründet Google die Änderungen mit einer effizienteren internen Entwicklung und weniger Konflikten beim Code-Merging. Doch in der Community stellt sich die Frage:

• Ist das nur eine technische Neuausrichtung – oder steckt auch Kalkül dahinter?
• Will Google verhindern, dass Pixel-Geräte weiterhin die bevorzugte Basis für Custom-ROMs bleiben?

Denn eines ist klar: Je mehr Hürden Google aufbaut, desto weniger Entwickler werden sich die Mühe machen, eigene ROMs für Pixel-Smartphones zu pflegen. Für ein Unternehmen, das seine Geräte stärker in ein eigenes Ökosystem bindet, wäre das kein Nachteil.

Kontrolle vs. Offenheit

Auf den ersten Blick wirkt Googles Entscheidung auch rein technisch begründet – weniger Code-Zweige, effizientere Entwicklungsprozesse, einheitliche Referenzplattform (Cuttlefish). Doch wenn man etwas genauer hinschaut kann man auch folgendes daraus ableiten:

• Kontrolle über das Ökosystem:
  Mit jedem Schritt, der die Arbeit der Custom-ROM-Community erschwert, stärkt Google die Bindung von Nutzern an die hauseigenen Pixel-ROMs. Wer keine funktionierenden Alternativen mehr hat, bleibt automatisch länger im offiziellen Android-Ökosystem – inklusive Google-Diensten.
• Annäherung an Apples Modell:
  Apple kontrolliert sowohl Hardware als auch Software strikt. Google hat mit den Pixel-Geräten eine ähnliche Strategie aufgebaut, allerdings bislang mit mehr Offenheit für Entwickler. Das aktuelle Vorgehen könnte ein Schritt in Richtung stärker geschlossener Systeme sein.
• Sicherheits-Argument als politisches Werkzeug:
  Google könnte die Einschränkungen offiziell mit höheren Sicherheitsanforderungen begründen. Weniger Transparenz für Kernel und Treiber erschwert nicht nur Custom-ROMs, sondern auch den Zugriff für Sicherheitsforscher. Dadurch behält Google mehr Kontrolle darüber, welche Sicherheitslücken öffentlich sichtbar werden – ein zweischneidiges Schwert.
• Einfluss auf die Open-Source-Szene:
  Pixel-Geräte waren jahrelang eine Art "Schaufenster" für Android-Offenheit. Wenn selbst Google diese Referenzgeräte nicht mehr offenlegt, sendet das ein Signal an andere Hersteller: Offenheit ist optional, Kontrolle ist Standard. Das könnte die gesamte Landschaft der offenen Android-Entwicklung langfristig verändern.
• Wirtschaftliche Interessen:
  Custom-ROMs wie GrapheneOS oder CalyxOS sind vor allem deshalb beliebt, weil sie Google-Dienste teilweise ersetzen oder ganz entfernen. Wer Custom-ROMs erschwert, schützt indirekt das eigene Geschäftsmodell: Google verdient am Datenzugriff und an der Integration seiner Services – nicht daran, dass Nutzer sich davon befreien.

Fazit

Die Schlagzeilen vom „Ende der Custom-ROMs“ sind übertrieben – Custom-ROMs werden nicht verschwinden. Aber: Google hat mit dieser Entscheidung die Weichen gestellt, die Entwicklung zumindest deutlich mühsamer zu machen.

Ob dies nur eine Folge interner Umstrukturierungen ist oder ein gezielter Versuch, die Community auszubremsen, bleibt offen. Fakt ist: Die Custom-ROM-Szene wird überleben – aber sie wird härter kämpfen müssen als bisher.

The post Google erschwert Custom-ROMs für Pixel-Geräte appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Führungswechsel bringt Entwicklung zum Stillstand

Laut der Bekanntmachung hat Nicholas Merrill, Präsident und Gründer des Calyx Institute, die Organisation verlassen, um sich neuen Projekten zu widmen.
Auch Chirayu Desai, technischer Leiter von CalyxOS, hat seinen Abschied bekanntgegeben. In einem Reddit-Post schrieb er:

„Android verändert sich – also dachte ich, es ist Zeit, dass ich mich auch verändere.“

Der Weggang der beiden hinterlässt eine deutliche Lücke. Das verbleibende Team kündigt eine Übergangsphase an, in der es sich intern neu organisieren will – unter Beibehaltung der bisherigen Sicherheitsprozesse. Ziel sei es, Transparenz und Sicherheit durch besseres Design, optimierte Kommunikation und modernisierte Infrastruktur zu steigern.

Keine Updates bis zu einem halben Jahr

Geplante Maßnahmen sind unter anderem:

• Modernisierung der technischen Infrastruktur für die CalyxOS-Entwicklung
• Stabilisierung der Update-Zyklen für die mehr als 25 unterstützten Geräte
• Überarbeitung und Aktualisierung der Dokumentation, Wikis und Benutzerhandbücher

Nach eigenen Schätzungen wird dieser Prozess vier bis sechs Monate dauern. Erst danach soll wieder das angestrebte Sicherheitsniveau erreicht werden.

Sicherheitsrisiko für bestehende Nutzer

Während dieser Umstrukturierung passiert etwas Kritisches:
CalyxOS stellt den Signier- und Verifikationsprozess auf neue Signaturschlüssel um.
Das hat zur Folge:

• Bestehende CalyxOS-Geräte erhalten in dieser Zeit keine Sicherheitsupdates
• Neue Nutzer können vorerst keine CalyxOS-Versionen herunterladen

Das Team warnt ausdrücklich, dass in dieser Phase keine aktuellen Sicherheitspatches des Android Open Source Project (AOSP) oder der Gerätehersteller eingespielt werden.
Man verstehe, wenn Nutzer in der Zwischenzeit zu einer anderen Android-Distribution wechseln, die weiterhin regelmäßige Updates liefert.

Wichtiger Hinweis zu zukünftigen Updates

Durch den geplanten Wechsel der Signaturschlüssel ist ein direktes OTA-Update von der aktuell installierten CalyxOS-Version auf die kommende, „gesicherte“ Version nicht möglich.
Alle bestehenden Installationen – ebenso wie Neuinstallationen während der Übergangsphase – müssen später komplett neu geflasht werden, sobald die neue Version verfügbar ist.
Dabei werden alle Daten gelöscht, weshalb ein vollständiges Backup (z. B. mit Seedvault) vorab unbedingt empfohlen wird.

Risikoanalyse & Empfehlung: CalyxOS ohne Sicherheitsupdates weiter nutzen

1. Aktuelle Situation

CalyxOS erhält in der Übergangsphase vier bis sechs Monate lang keine Sicherheitsupdates.
In dieser Zeit bleiben bekannte und unbekannte Sicherheitslücken in Android und den Gerätetreibern offen.
Die Gefahr steigt, je älter die Software wird, da monatlich neue Schwachstellen veröffentlicht und oft aktiv ausgenutzt werden.

2. Haupt-Risiken

1. Schadsoftware & Exploits
   • Ohne aktuelle Patches kann ein Angreifer bekannte Lücken gezielt ausnutzen.
   • Besonders kritisch: Lücken in WebView/Browser, Bluetooth, WLAN oder Medienbibliotheken.
2. Zugriff auf persönliche Daten
   • Bei kompromittiertem System können gespeicherte Passwörter, Nachrichten oder 2FA-Tokens abgegriffen werden.
3. Gerätemissbrauch
   • Angreifer könnten das Gerät als Teil eines Botnets nutzen oder heimlich Mikrofon/Kamera aktivieren.
4. Kein OTA-Update auf die neue Version
   • Später ist ein kompletter Neu-Flash nötig (inkl. Datenlöschung).

3. Risikoeinschätzung für normale Nutzer

• Niedrig bis mittel, wenn:
  • Gerät nur privat genutzt wird
  • Keine Installation unbekannter Apps
  • Vorsichtiger Umgang mit Links, Anhängen und öffentlichen WLANs
• Mittel bis hoch, wenn:
  • Viel Surfen im Internet
  • Nutzung unsicherer Apps oder APK-Seiten
  • Berufliche Nutzung mit sensiblen Daten

4. Empfehlung

• Variante A – Vorsichtig bleiben & warten
  • Gerät bis zur neuen Version behalten, aber:
    • Nur Apps aus F-Droid oder Play Store mit gutem Ruf installieren
    • Browser und sicherheitskritische Apps (Signal, Element, etc.) regelmäßig intern updaten
    • Unbekannte WLANs und Bluetooth möglichst deaktivieren
    • Kein Banking, keine sensiblen Logins in dieser Zeit, wenn möglich
  • Vor Neuinstallation: Seedvault-Backup erstellen und extern sichern (USB, SD, Nextcloud).
• Variante B – Sofort wechseln
  • Umgehen der Sicherheitslücke durch Wechsel auf GrapheneOS, /e/ OS oder Stock Android.
  • Backup via Seedvault oder Neo Backup, anschließend direkt sicherere Plattform nutzen.

Wer keine besonders sensiblen Daten auf dem Gerät hat und vorsichtig mit Internet & Apps umgeht, kann CalyxOS noch einige Monate nutzen – sollte sich aber bewusst sein, dass das Risiko mit jedem Monat ohne Updates steigt.
Für sicherheitsbewusste Nutzer ist ein sofortiger Wechsel die bessere Wahl.

Hilfe beim Wechsel

Für Nutzer, die CalyxOS dennoch deinstallieren möchten, kündigt das Team Unterstützung an:
Es gibt man Anleitung zur Sicherung und Wiederherstellung von Smartphones mit Seedvault veröffentlichen – sowohl für den Umstieg auf Standard-Android als auch auf andere Custom-ROMs oder auf die neue CalyxOS Version nach der Übergangsphase

https://calyxos.org/docs/guide/apps/seedvault

Diese Anleitung hilft aber herzlich wenig, wenn man z.B. auf GrapheneOS umsteigen will, den damit es die Seedvault Version von CalyxOS nicht vollständig kompatibel.

Auch wir von yourdevice.ch bitten aktive Hilfe beim Wechsel auf GrapheneOS an. Kunden können manuelle Backups Zuhause machen und das Telefon danach einsenden. Wir spielen dann GrapheneOS für alle Kunden auf, die sich ein Phone mit CalyxOS bei uns gekauft haben und erhalten einen persönlichen Rabatt und zahlen nur 49CHF anstatt 79CHF für die Installation für GrapheneOS. Bitte dazu Email an: [email protected]

Nützliche Links für manuelle Backups auf GrapheneOS:

https://yourdevice.ch/daten-auf-customrom-mit-calyxos-grapheneos-uebertragen/

https://yourdevice.ch/android-backup-mit-nextcloud/

https://yourdevice.ch/nextcloud-kalender-mit-android-synchronisieren/

https://yourdevice.ch/kontakte-synchronisieren-mit-nextcloud-android-und-thunderbird/

Fazit

CalyxOS befindet sich aktuell in einer kritischen Übergangsphase, in der keine Sicherheitsupdates bereitgestellt werden.
Der Wechsel der Signaturschlüssel bedeutet, dass bestehende Installationen später nicht per OTA aktualisiert werden können – ein kompletter Neu-Flash mit anschließendem Daten-Import (z. B. via Seedvault) wird zwingend nötig sein.

Für Nutzer stellt sich jetzt die Frage: bleiben oder wechseln?
Wer sein Gerät nur privat nutzt, vorsichtig mit Apps und Internet umgeht und keine hochsensiblen Daten speichert, kann CalyxOS vorübergehend weiterverwenden – sollte sich aber der wachsenden Risiken bewusst sein und zum Release der neuen Version vorbereitet sein.
Wer dagegen beruflich oder mit sensiblen Informationen arbeitet oder maximale Sicherheit benötigt, sollte sofort auf eine aktiv gepflegte Android-Distribution wie GrapheneOS.

Egal für welchen Weg man sich entscheidet: Ein vollständiges Backup ist sinnvoll – nur so lässt sich später ein reibungsloser Wechsel sicherstellen.

Man kann das ganze auch positiv sehen, und es als Gelegenheit wahrnehmen, endlich auf das deutlich sicherere GrapheneOS umzusteigen.

The post CalyxOS: Android-Custom-ROM legt Entwicklung auf Eis appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was sind die Google Fonts Schriftarten

Google Fonts ist ein beliebtes Tool, das Webentwicklern kostenlos eine Vielzahl von Schriftarten bietet. Die Benutzerfreundlichkeit und die große Auswahl an Schriftarten haben es zu einem Standard in der Webentwicklung gemacht. Aber wie bei vielen kostenlosen Diensten stellt sich oft die Frage: „Wenn man nicht für das Produkt bezahlt, ist man vielleicht das Produkt selbst?“ In Bezug auf Google Fonts geht es um die Datensammlung.

Die Hauptproblematik liegt hierbei nicht unbedingt in der Datensammlung selbst – schließlich sammeln viele Dienste Daten, um ihre Angebote zu optimieren. Es ist jedoch die fehlende Transparenz und Aufklärung, die hier kritisch betrachtet werden muss. Viele User sind sich überhaupt nicht bewusst, dass ihre Daten durch den bloßen Besuch einer Website, die Google Fonts verwendet, erfasst werden. Die Datensammlung geschieht still und heimlich im Hintergrund, und die meisten User werden niemals davon erfahren.

Technischer Hintergrund der Google Fonts Schriftarten Datensammlung

Wenn eine Webseite Google Fonts verwendet, muss sie in der Regel einen Verweis zu Googles Servern herstellen, um die gewünschte Schriftart zu laden. Dies geschieht durch das Einfügen eines speziellen Links in den HTML-Code der Seite, der auf eine CSS-Datei auf Googles Servern zeigt. Diese CSS-Datei enthält Anweisungen zum Laden der Schriftart.

Wie es funktioniert

Wann immer ein Benutzer eine Webseite besucht, die Google Fonts verwendet, sendet sein Browser eine Anfrage an Googles Server, um die Schriftart herunterzuladen. Bei dieser Anfrage werden verschiedene Daten übermittelt:

1. Die IP-Adresse des Benutzers.
2. Der User-Agent-String des Browsers, der Informationen über den Browsertyp und das Betriebssystem des Benutzers enthält.
3. Die Webseite, von der die Anfrage stammt.
4. Weitere technische Details, wie z.B. die Bildschirmauflösung oder Spracheinstellungen des Browsers.

Diese Daten können potenziell dazu verwendet werden, um Nutzerprofile zu erstellen, insbesondere wenn sie mit anderen Daten kombiniert werden, die Google durch seine zahlreichen Dienste sammelt.

Warum ist das problematisch

Die Sammlung von Daten durch Google Fonts mag auf den ersten Blick harmlos erscheinen, insbesondere im Vergleich zu den weitreichenderen Datensammlungspraktiken, die in anderen Teilen des Internets vorkommen. Aber es gibt einige Bedenken:

1. Verfolgung: Auch wenn die durch Google Fonts gesammelten Daten für sich genommen möglicherweise nicht sehr aussagekräftig sind, können sie, wenn sie mit anderen Daten kombiniert werden, dazu beitragen, ein detailliertes Profil eines Benutzers zu erstellen.
2. Zentralisierung: Die weit verbreitete Nutzung von Google Fonts trägt zur weiteren Zentralisierung des Internets bei. Eine solche Zentralisierung kann zu einem Single Point of Failure werden und potenziell die Privatsphäre und die Datensicherheit gefährden.

Technischer Hintergrund

Einbindung auf Websites
Webentwickler binden Google Fonts typischerweise so ein:

<link href="proxy.php?url=https://fonts.googleapis.com/css?family=Roboto" rel="stylesheet">

Diese CSS-Datei verweist wiederum auf weitere Dateien (die eigentlichen Schriftarten im WOFF2-, WOFF- oder TTF-Format), ebenfalls von Googles Servern.

Ablauf beim Seitenaufruf

• Browser ruft fonts.googleapis.com auf (CSS-Datei)
• CSS verweist auf fonts.gstatic.com (Font-Datei)
• Dabei übermittelt der Browser automatisch:
  • IP-Adresse (erkennbar als eindeutiger Zugriffspunkt)
  • User-Agent (Browser, Betriebssystem, Version)
  • Referrer (Seite, von der der Aufruf kommt)
  • Spracheinstellungen, teilweise Bildschirmauflösung, Rendering-Engine
• Google kann diese Daten mit anderen gesammelten Informationen verknüpfen.

Besonderheit
Selbst wenn die Fonts im Browser-Cache liegen, kann der erste Abruf einer Seite bereits Tracking ermöglichen.

Welche Auswirkungen hat dies aus datenschutzrechtlicher Perspektive

1. Mangelnde Transparenz: Google bietet keine klaren Informationen darüber, welche Daten genau gesammelt werden und wie sie verwendet werden, wenn jemand eine Website besucht, die Google Fonts nutzt.
2. Unwissenheit der User: Viele User sind sich nicht bewusst, dass ihre Daten gesammelt werden, und haben dementsprechend keine Möglichkeit, sich dagegen zu entscheiden oder ihre Zustimmung zu geben.
3. Verantwortung der Web-Entwickler: Während Google die Tools bereitstellt, liegt es oft in der Verantwortung der Web-Entwickler und Website-Betreiber, sich über Datenschutzbestimmungen im Klaren zu sein und ihre User darüber zu informieren.
4. Potenzielles Missbrauchspotenzial: Wenn Daten gesammelt werden, besteht immer das Risiko, dass sie missbraucht oder ohne Zustimmung an Dritte weitergegeben werden.
5. Beeinträchtigung der demokratischen Werte: In einer Gesellschaft, die den Datenschutz und die Privatsphäre hochhält, sollte jeder Bürger das Recht haben zu wissen, welche seiner Daten gesammelt werden und warum.

Die heimliche Datensammlung durch Google Fonts ist ein weiteres Beispiel dafür ist, wie große Technologieunternehmen oft im Verborgenen agieren. Es ist essenziell, dass sowohl User als auch Web-Entwickler sich der Risiken bewusst sind und aktiv Maßnahmen ergreifen, um den Datenschutz zu gewährleisten.

Google wurde für dieses Verhalten jedoch nicht belangt. Geschädigt sind die Benutzer die Abmahnungen von Geldgierigen erhielten, die diesen Fall ausnutzten.

Wie schütze ich mich vor dem laden von Google Fonts

Für Endnutzer auf dem PC

1. Browser-Erweiterungen:
   • Privacy Badger (Firefox, LibreWolf, Waterfox etc.) – blockiert standardmäßig Google Fonts.
   • uBlock Origin – kann gezielt fonts.googleapis.com und fonts.gstatic.com blockieren.
2. Systemweite Blockade:
   • Linux/macOS:

öffnet die Datei:

sudo nano /etc/hosts

und tragt folgendes in die Datei ein wie im Screenshot zu sehen:

127.0.0.1 fonts.googleapis.com
127.0.0.1 fonts.gstatic.com

Eine Versuch Eures Systems fonts.googleapis.com aufzurufen läuft damit ins Leere:

3. DNS-Filter nutzen:
Pi-hole, AdGuard Home oder NextDNS – blockiert Google Fonts auf allen Geräten im Netzwerk.

Für Endnutzer auf dem Android Smartphone

Auf Android könnt Ihr Euch gegen das Nachladen von Google Fonts ähnlich wie am PC schützen, aber die Methoden unterscheiden sich, weil Ihr keinen direkten Zugriff auf /etc/hosts habt und viele Browser-Apps eigene Regeln verwenden.
Hier sind die praktischsten Ansätze – von „einfach“ bis „technisch fortgeschritten“:

Browser mit integriertem Tracker-Blocker verwenden

• Bromite
  Hat integrierten Content-Blocker und kann Domains wie fonts.googleapis.com direkt blockieren.
• Firefox / Fennec / Mull
  In Kombination mit uBlock Origin oder Privacy Badger lassen sich Google Fonts gezielt blockieren:
  1. uBlock Origin installieren
  2. In den Filterlisten fonts.googleapis.com und fonts.gstatic.com blockieren.
• Brave
  Blockt standardmäßig viele Tracker, Google Fonts aber nicht immer. Unter Einstellungen → Schutz → Erweitert zusätzlich die Blockierung von Drittanbieter-Ressourcen aktivieren.

Systemweite DNS-Blockade (ohne Root)

Mit einem DNS-Filter könnt Ihr Google Fonts auf dem ganzen Gerät blockieren – unabhängig von der App.

• NextDNS (https://nextdns.io)
  → Eigene Sperrliste erstellen und fonts.googleapis.com sowie fonts.gstatic.com blockieren.
• AdGuard DNS
  → Vorinstallierte Tracking-Sperrlisten aktivieren.
• Quad9 oder ControlD mit Custom Rules.

Wie man auf Android einen Systemweiten DNS aktiviert, erfahrt ihr hier und hier.

Kurz gesagt benutzt ihr dafür spezielle DNS Server die solche Tracker blockieren:
Einstellungen → Netzwerk & Internet → Privates DNS aktivieren und die gewünschte DNS-Server-Adresse eintragen.

Werbe- und Tracker-Blocker als eigenständige App

• AdGuard (lokales VPN ohne Root)
  → Blockiert gezielt Google Fonts, auch in In-App-Browsern.
• RethinkDNS (Open Source)
  → DNS-Blocklisten + Firewall-Funktion.

Für Website-Betreiber

1. Fonts lokal hosten:
   • Google Fonts herunterladen (z. B. über https://gwfh.mranftl.com/)
   • Dateien ins eigene Webserver-Verzeichnis legen und lokal einbinden.
2. CSS-Optimierung:
   • Nur tatsächlich verwendete Schriftschnitte einbinden (reduziert Ladezeit und Datenübertragung).
3. Fallback-Schriften definieren:
   • Falls Fonts blockiert werden, eine ähnliche Systemschriftart als Ersatz angeben.

Fazit

Google Fonts sind bequem, aber datenschutzrechtlich problematisch, wenn sie direkt von Googles Servern geladen werden. Wer Wert auf Privatsphäre legt – ob als Website-Betreiber oder als Nutzer – sollte Fonts lokal einbinden oder blockieren. So bleibt nicht nur die Kontrolle über die Daten erhalten, sondern man reduziert auch unnötige externe Abhängigkeiten.

Quellen:

https://www.netzwoche.ch/news/2023-05-25/gerichtsurteil-google-fonts-abmahnungen-sind-ungerechtfertigt

https://www.hubit.de/google-tracking-von-admins-und-web-besuchern-mit-google-fonts/

The post Google Fonts und die heimliche Datensammlung mit Schriftarten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Eine pruned Node ist also eine Bitcoin-Fullnode, die nicht die gesamte Blockchain speichert, sondern nur die aktuellen und relevanten Daten, die sie für die Validierung neuer Blöcke und Transaktionen benötigt.

Wie funktioniert Pruning technisch?

• Sobald eine Node vollständig synchronisiert ist (also alle Blöcke heruntergeladen und geprüft hat), kann sie alte Blöcke löschen.
• Dies geschieht durch die Einstellung:

prune=

#setzt man hier z.B. prune=100000, werden nur die letzten 100GB an Blockdaten gespeichert.

• im bitcoin.conf. Die Zahl gibt die Größe des Speichers in MB an, den die Node maximal für Blöcke verwenden darf.
• Bitcoin Core löscht dann automatisch die ältesten Blöcke, nachdem sie vollständig verarbeitet wurden.
• UTXO-Daten (unspent transaction outputs) bleiben erhalten – das ist entscheidend, denn sie sind nötig, um neue Transaktionen zu validieren.

Wichtig: Nur Blöcke können gepruned werden. Der UTXO-Set, also die Menge aller noch nicht ausgegebenen Coins, muss immer vollständig vorhanden sein.

Ein Stratum Server für das Bitcoin Mining kommt hiermit nur 550MB an Blöcken aus, mehr braucht er nicht, da er Blocktemplates immer nur anhand des neusten Blockes zur Verfügung stellt, mehr nicht.

Vorteile von Pruning

Nachteile von Pruning

Für wen ist Pruning sinnvoll?

Pruning eignet sich perfekt für:

• Privatnutzer, die ihre eigene Node betreiben möchten
• Raspberry Pi-Setups mit begrenztem Speicher z.B einer alten 1TB Platte.
• Wallet-Validierung zu Hause, um nicht auf Dritte angewiesen zu sein
• Netzwerk-Teilnehmer, die zur Dezentralisierung beitragen wollen, ohne hunderte GB speichern zu müssen
• Pool Betreiber: benötigen nicht die komplette Chain um Templates zur Verfügung zu stellen

Nicht geeignet ist es für:

• Blockexplorer
• öffentliche Electrum-Server
• Lightning-Setups, die Wallet-Rescans benötigen
• Developer, die tief in die Blockchain schauen müssen

Pruning Möglichkeiten nach vollständiger Synchronisation

Node synchronisiert, ohne Pruning

Bitcoin Core erlaubt es, den prune-Wert (z.B. prune=100000, was ~100 GB entspricht) auch nach einem vollständigen Blockchain-Sync zu setzen, ohne dass ein Reindex durchgeführt werden muss. Beim nächsten Start mit aktiviertem Pruning beginnt der Node automatisch damit, alte Blöcke zu löschen, bis der Speicherverbrauch unter dem angegebenen Zielwert liegt (bitcoin.stackexchange.com). Es ist also keine erneute Synchronisation der gesamten Blockchain nötig – im Gegenteil, durch das Pruning wird Festplattenplatz freigegeben. (Nur wenn man später von einem geprunten Node zurück zu einem ungeprunten wechseln möchte, wäre ein erneutes Herunterladen/Reindexieren der Blockchain erforderlich (bitcoincore.org.)

Beispielsweise beträgt der minimale zulässige Prune-Wert 550 MB, was sicherstellt, dass mindestens die letzten 288 Blöcke (ca. 2 Tage) aufbewahrt werden (bitcoincore.org). Dieser Mindestwert wurde gewählt, um kurzfristige Reorganisationen oder Wallet-Rescans zu ermöglichen. Höhere Werte wie prune=100000 bedeuten entsprechend mehr aufbewahrte Blöcke (100 GB entspricht grob den letzten ~1–2 Jahren an Blöcken, je nach Blockgröße). Die Umstellung von einem vollständigen Node auf einen geprunten Node erfolgt nahtlos: Bitcoin Core erkennt die vorhandenen Blockdaten und entfernt ältere Blöcke, bis das Speicherlimit erreicht ist. Ein Reindex oder Neu-Download ist dafür nicht erforderlich (bitcoin.stackexchange.com). Es empfiehlt sich allerdings, vor dem Pruning ein Backup der Wallet anzulegen und sicherzustellen, dass kein Wallet-Rescan nötig ist, der in pruned Mode mangels alter Blöcke fehlschlagen würde (siehe nächste Sektion zur Wallet-/Lightning-Problematik).

Node synchronisert jedoch mit aktiviertem Pruning

Sobald Ihr in Eurer bitcoin.conf z. B. prune=10000 gesetzt habt, betreibt Bitcoin Core Eure Node im sogenannten Pruned Mode. Das bedeutet:

• Alte Blöcke werden dauerhaft gelöscht, sobald sie nicht mehr zum Validieren benötigt werden.
• Das betrifft nicht nur die Blöcke selbst, sondern teilweise auch Metadaten, die zur Verwaltung der Chain notwendig sind.

Wenn Ihr nun nach einiger Zeit entscheidet, dass Ihr doch alle Blöcke behalten möchtet – z. B. für einen Blockexplorer, Electrum-Server oder zur Archivierung –, reicht es nicht, einfach den prune-Eintrag zu entfernen oder auf prune=0 zu setzen.

Warum ein einfacher Wechsel nicht funktioniert

Eine geprunte Node hat nur einen Teil der Blockchain auf der Festplatte – z. B. nur die letzten 10 GB (≈1 Jahr Blockchain-Historie). Wenn Ihr jetzt prune=0 in die bitcoin.conf schreibt:

• Bitcoin Core erkennt, dass viele Blöcke fehlen.
• Da ein vollständiger Node aber die komplette Blockchain seit Genesis-Block (2009) benötigt, ist das System nicht mehr vollständig.
• Deshalb bricht Bitcoin Core mit einem Fehler ab und fordert Euch auf, die Blockchain neu zu synchronisieren.

Die einzige Möglichkeit, wieder eine vollständige Node zu betreiben, ist:

bitcoind -reindex

Oder Ihr löscht das komplette .bitcoin/blocks und .bitcoin/chainstate Verzeichnis (bzw. Euer entsprechendes datadir) und startet den Sync komplett neu – diesmal ohne prune=….

Prune-Größe und Lightning: Mindestanforderungen

Für den Betrieb von Lightning-Nodes (LND oder Core Lightning) auf einem geprunten Bitcoin-Core-Backend gelten besondere Anforderungen an die Blockverfügbarkeit. Zwar können beide Lightning-Implementierungen grundsätzlich mit einem geprunten Full Node funktionieren (bitcoin.stackexchange.com), jedoch dürfen keine für Lightning relevanten Blöcke gelöscht werden, da sonst die Lightning-Software wichtige on-chain Ereignisse nicht nachverfolgen kann. In der Praxis bedeutet das:

• Alle Blöcke seit Erzeugen der Lightning-Wallet bzw. seit der ältesten aktiven Channel-Eröffnung müssen verfügbar bleiben (dev.lightning.community). Die offizielle LND-Dokumentation betont, dass bei Verwendung eines geprunten Nodes sichergestellt sein muss, dass LND alle Blöcke seit dem „Geburtszeitpunkt“ der Wallet und seit dem Alter des ältesten Channels auf der Festplatte hat (dev.lightning.community). Andernfalls könnte LND Transaktionen (z.B. eine alte Funding- oder Closing-Transaktion) nicht mehr nachträglich finden, falls ein Rescan nötig wird.
• Ein Lightning-Node darf nicht zu weit hinter der Blockchain zurückfallen, da ein geprunter Bitcoin-Core alte Blöcke nicht mehr liefern kann. Die Core-Lightning-Dokumentation warnt ausdrücklich: Wenn bitcoind einen Block bereits geprunt hat, den Core Lightning noch nicht verarbeitet hat (etwa weil der Lightning-Daemon länger offline war), kann Core Lightning sich nicht mehr synchronisieren und bleibt stecken (docs.corelightning.org). Ähnliches gilt für LND – es ist möglich, dass LND beim Aufholen der Blockchain eine benötigte bestätigte Transaktion (z.B. eine Channel-Schließung) nicht mehr über RPC abrufen kann, wenn der betreffende Block inzwischen gelöscht wurde. In solchen Fällen kann LND aus dem Sync fallen (zeigt z.B. synced_to_chain = false) und benötigt einen manuellen Eingriff oder Neustart (github.com).

Angesichts dieser Anforderungen ist die minimal mögliche Prune-Größe von 550 MB (≈288 Blöcke) für zuverlässigen Lightning-Betrieb meist nicht ausreichend. 288 Blöcke entsprechen nur zwei Tagen: Würde der Lightning-Node z.B. eine Woche offline sein, wären die fehlenden ~1008 Blöcke bereits nicht mehr alle auf der Disk vorhanden, was zu Synchronisationsproblemen führt. Zudem bleiben Lightning-Channels oft deutlich länger als zwei Tage offen – die Blöcke der Channel-Eröffnungen würden bei aggressivem Pruning irgendwann entfernt. Ein Lightning-Node prüft jedoch beim Start typischerweise den Status seiner Funding-Transaktionen (und gegebenenfalls deren Bestätigungen) in der Blockchain. Wenn diese ursprünglichen Funding-Blöcke geprunt sind, kann es zu Fehlern oder hängenden Channels kommen (ein früher c-lightning-Bug zeigte z.B., dass bei prune=550 Lightning beim Start ~96 Blöcke hinterherhinkte, da ein benötigter Block “Block not available (pruned data)” wargithub.com).

Praktisch bewährte Empfehlung: Verwende einen deutlich höheren Prune-Wert, um einen ausreichenden Puffer an Blöcken vorzuhalten. Häufig genannte Werte sind mindestens 5–10 GB statt nur 550 MB. Beispielsweise empfiehlt ein Entwickler des Node Launcher (LND-Launcher) mindestens prune=10000 (≈10 GB) oder mehr freien Speicher, damit das Pruning nicht zu aggressiv ausfällt (github.com). Auch Anwenderberichte zeigen, dass stärkeres Pruning die Stabilität von LND beeinträchtigen kann („je aggressiver man prunet, desto häufiger verliert LND die Synchronisation mit der Chain“(github.com). Mit ~10 GB Pruning-Limit bleiben grob die letzten 1–2 Monate an Blöcken erhalten, was kurze Offline-Zeiten problemlos überbrückt. Wer sicherstellen will, dass auch sehr alte Channels (z.B. seit 2018) abgedeckt sind, müsste entsprechend einen viel größeren Wert oder gar kein Pruning einstellen – einige Routing-Node-Betreiber verzichten daher auf aggressives Pruning zugunsten der Zuverlässigkeit (docs.lightning.engineering). Zusammengefasst sollte die Prune-Größe so gewählt werden, dass die ältesten relevanten Blöcke für Ihre Lightning-Channels nicht gelöscht werden.

Unterschiede zwischen LND und Core Lightning

Beide Lightning-Implementierungen haben grundsätzlich dieselbe Herausforderung: Sie benötigen Zugriff auf bestimmte Blockchain-Daten (Blocks/Transactions), um Channel-Funding und -Closing sowie on-chain HTLC-Timeouts etc. überwachen zu können. Allerdings gibt es leichte Unterschiede in der offiziellen Haltung und Handhabung:

• LND (Lightning Labs) – LND unterstützt seit Bitcoin Core 0.16+ zwar den Betrieb mit einem geprunten Backend, steht dem aber noch etwas vorsichtig gegenüber. In der Doku heißt es klipp und klar, dass pruned Nodes nicht vollständig unterstützt werden und der Nutzer selbst sicherstellen muss, dass alle benötigten Blöcke vorhanden sind (dev.lightning.community). LND benötigt keinen txindex (es kann fehlende Transaktionen notfalls über das P2P-Netz laden), aber wenn ein benötigter Block fehlt, gerät LND ins Hintertreffen. In der Praxis zeigt sich, dass LND bei sehr knappem Pruning gelegentlich den Sync verliert und manuell neu gestartet werden muss (github.com). Die Entwickler arbeiten zwar an Verbesserungen (z.B. Unterstützung von BIP157/158 Blockfiltern und manueller Prune-Steuerung(github.comgithub.com), dennoch sollte man LND mit Vorsicht prunen.
• Core Lightning (ehem. c-lightning, Blockstream) – Core Lightning wird von Haus aus häufig mit geprunten Nodes betrieben und gilt als prune-freundlich. Offiziell heißt es, Core Lightning benötige lediglich einen vollständig synchronisierten bitcoind und verwendet JSON-RPC (kein txindex nötig) (docs.corelightning.orgdocs.corelightning.org). Allerdings warnt auch CLN: Wenn der Bitcoin-Core einen Block schon gelöscht hat, bevor Core Lightning ihn verarbeiten konnte (etwa wegen längerer Downtime von CLN), kann CLN nicht mehr aufholenn (docs.corelightning.org). Daher empfiehlt man, die Differenz zwischen der von CLN verarbeiteten Blockhöhe und der aktuellen bitcoind-Höhe im Auge zu behalten und notfalls einzugreifen, bevor die Lücke zu groß wird (docs.corelightning.org). Insgesamt wird Core Lightning als etwas robuster gegenüber Pruning gesehen, weil es z.B. bei Bedarf einzelne TXOs direkt über RPC (gettxout) prüfen kann, ohne ganze Blöcke laden zu müssen. Auch BTCPay Server empfiehlt bei Nutzung eines geprunten Bitcoin-Nodes eher Core Lightning, da diese Implementation offiziell pruned Nodes unterstützt und damit zuverlässiger läuft (docs.btcpayserver.org). LND kann zwar ebenfalls mit Pruning funktionieren, erfordert aber sorgfältigere Konfiguration und Überwachung.

Beide Lightning-Implementierungen können mit einem geprunten Bitcoin Core betrieben werden, jedoch sollte man großzügig prunen (lieber einige Dutzend GB statt das Minimum), um eine zuverlässige Funktion sicherzustellen. Core Lightning wird von vielen als die bessere Wahl erachtet, falls man mit starkem Pruning arbeiten muss: (docs.btcpayserver.org), während LND bei knapper Blockhistorie eher zu Synchronisationsproblemen neigt (github.com). In jedem Fall sind offizielle Dokumentationen und Warnhinweise zu beachten, und man sollte im Zweifel eher mehr Blockchain-Daten vorhalten, insbesondere wenn der Lightning-Node nicht durchgängig online ist.

Fazit

Pruning ist eine smarte Möglichkeit, eine vollwertige Bitcoin-Node zu betreiben, ohne mehrere Hundert Gigabyte Speicher zu verbrauchen. Für viele Nutzer reicht die reduzierte Funktionalität vollkommen aus, solange man keine tiefergehenden Dienste wie Adress-Indexierung oder historische Analysen benötigt.

Wer jedoch Blockexplorer, Lightning-Dienste oder Electrum-Server betreiben möchte, muss auf eine vollständige, ungeprunete Node mit vollem Blockchain-Archiv setzen.

The post Was ist Pruning und welche Vor- und Nachteile gibt es appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was sind Passkeys

Passkeys sind eine moderne Authentifizierungsmethode, die klassische Passwörter ablösen soll. Technisch beruhen sie auf einem Verfahren namens Public-Key Cryptography (asymmetrische Kryptographie), konkret der WebAuthn- und FIDO2-Standards.

Statt ein Passwort einzugeben, erzeugt Euer Gerät ein Schlüsselpaar:

• Privater Schlüssel: bleibt sicher auf Eurem Gerät und wird nie übertragen.
• Öffentlicher Schlüssel: wird an den Dienst übergeben, z.B. an den Login-Server.

Beim Einloggen:

1. Der Server sendet eine Challenge (eine Art „Einmal-Code“).
2. Euer Gerät signiert diese Challenge mit dem privaten Schlüssel.
3. Der Server prüft anhand des gespeicherten öffentlichen Schlüssels, ob die Signatur korrekt ist.
4. Falls ja, seid Ihr eingeloggt.

Dadurch kann kein Passwort abgefischt oder in einem Leak ausgespäht werden.

Passkeys werden oft mit Geräten verknüpft:

• Smartphones
• Hardware-Token (z.B. YubiKey)
• Laptop/PC (Trusted Platform Module)
• Browser und deren Cloud-Dienste (Google, Apple, Microsoft)

Vorteile von Passkeys

Hohe Sicherheit

• Keine wiederverwendbaren Passwörter
• Kein Phishing (Angreifer können keine „Geheimnisse“ abgreifen)
• Keine Datenbank-Leaks mit Passwörtern

Benutzerfreundlich

• Biometrie oder Gerätesperre reicht (Face ID, Touch ID, PIN)
• Kein Merken langer Passwörter

Schneller Login

• Ein Klick oder ein Fingerabdruck

Nachteile von Passkeys

Kommen wir zu den Nachteilen von Passkeys, den da gibt es aktuell noch jede Menge. Wir schauen uns die parallele Nutung von Passkeys und Passwörtern an, die Uneinheitliche Implementierung und das Vendor Lock-in Problem von BigTech, die Passkeys nutzen, um ihre Nutzer weiter an ihr Ökosystem zu binden.

Passkeys bringen nur dann Sicherheit, wenn Passwörter abgeschaltet werden

Ein weitverbreitetes Missverständnis ist, dass Passkeys automatisch alle Sicherheitsprobleme lösen, nur weil sie hinzugefügt wurden. In der Praxis sieht es aber oft so aus:

• Der Dienst erlaubt weiterhin den Login mit Eurem alten Passwort.
• Passkeys sind nur eine zusätzliche Option neben Benutzername + Passwort.
• Phishing-Angriffe, Credential Stuffing (also Angriffe mit geleakten Passwörtern) und andere Risiken bleiben bestehen.

Das bedeutet konkret:
Solange Euer Passwort weiter aktiv ist, ändert sich an der Gefährdungslage wenig. Angreifer können immer noch versuchen, sich mit dem Passwort einzuloggen – Passkeys verhindern das nur dann, wenn Ihr komplett auf „Passkey only“ umstellt und die Passwörter deaktiviert oder löscht.

Viele Plattformen machen es aber schwer, diesen Schritt konsequent zu gehen:

• Manche bieten gar keine Möglichkeit, Passwörter zu entfernen.
• Andere verstecken die Option tief in den Sicherheitseinstellungen.
• Einige Dienste unterstützen noch gar keinen reinen Passkey-Login.

Wichtiger Hinweis:
Der große Sicherheitsgewinn entsteht erst dann, wenn Ihr das Passwort als Fallback abschaltet. Nur so entzieht Ihr Angreifern die Chance, über alte oder geleakte Passwörter auf Euer Konto zuzugreifen.

Falls ein Dienst kein „Passkey only“-Login unterstützt, könnt Ihr überlegen, ob Ihr dort entweder:

• ein sehr langes, zufälliges Passwort in einem Passwortmanager erstellst (quasi als Notnagel), oder
• den Dienst nach Möglichkeit meidet, bis er Passkey-only einführt.

Kurz gesagt:

Wer Passkeys nur als „Zusatz“ verwendet, hat zwar Bequemlichkeit gewonnen – die alten Risiken bleiben aber weitgehend bestehen.

Erst die vollständige Abkehr von Passwörtern bringt den vollen Sicherheitsvorteil.

Vendor Lock-in & Plattformbindung

Hier kommen wir zu einem weiteren kritischen Teil:

Viele große Anbieter verknüpfen Passkeys mit ihren eigenen Ökosystemen, zum Beispiel:

• Apple: Speicherung in der iCloud Schlüsselbund. Ohne Apple-ID keine Wiederherstellung.
• Google: Speicherung im Google Password Manager. Ohne Google-Konto kein Zugriff.
• Microsoft: Speicherung im Microsoft-Account.
• Browser-Hersteller (Chrome, Edge, Safari): Verknüpfung mit dem jeweiligen Profil.

Das führt zu einer Bindung an den Anbieter!

Ihr werdet de facto an das Ökosystem gebunden, da ein Wechsel schwieriger ist als bei klassischen Passwörtern oder Passwortmanagern.

Beispiele:

• Ihr nutzt Safari und iCloud? Dann wird der Passkey nur in Eurem Apple-Ökosystem synchronisiert.
• Chrome und Google Password Manager? Euer Passkey liegt in der Google-Cloud.
• Firefox hat (noch) keine eigene Passkey-Synchronisation, hier muss man separate Hardware-Keys nutzen.

Beispiel für ein „ökosystemgebundenes“ Szenario

Ein Nutzer erstellt einen Passkey für seinen Google-Account mit Chrome. Dieser Passkey wird automatisch im Google Password Manager hinterlegt.
Später möchte er auf Firefox oder Safari wechseln, oder komplett Google verlassen – dann ist der Passkey ohne Migrationsschritt nicht verfügbar.
Es gibt noch kein standardisiertes, leicht nutzbares Export-/Importverfahren zwischen allen Plattformen.

Das ist einer der Hauptkritikpunkte an Passkeys derzeit:

• Sie erhöhen die Sicherheit
• Aber sie können dazu beitragen, Nutzer stärker an große Anbieter zu binden

Passkeys sorgen für Verwirrung

Ein Punkt, der viele Nutzer schnell durcheinanderbringt, ist die Frage:

Wo genau liegt mein Passkey – und wie finde ich ihn wieder?

Im Gegensatz zu Passwörtern, die Ihr bewusst eintippt oder in einem Passwortmanager seht, werden Passkeys meist unsichtbar im Hintergrund erstellt und in Eurem Gerät oder Eurem Benutzerkonto gespeichert. Das kann je nach Betriebssystem, Browser und Endgerät sehr unterschiedlich sein:

• Apple-Geräte: Passkeys landen automatisch in der iCloud Schlüsselbund, wenn Ihr iCloud aktiviert habt. Das heißt: Ohne Apple-ID und iCloud-Synchronisation kommt Ihr nicht mehr an Euren Passkey.
• Android und Chrome: Hier speichert der Google Password Manager den Passkey in Eurem Google-Konto. Viele merken gar nicht, dass sie ihn in der Cloud ablegen.
• Windows und Edge: Passkeys werden in Eurem Microsoft-Account gesichert.
• Hardware-Token (z.B. YubiKey): Der Passkey bleibt direkt auf dem Stick gespeichert, ohne Cloud.
• Manche Passwortmanager (Bitwarden, 1Password): Dort könnt Ihr Passkeys ebenfalls speichern – aber auch nur, wenn die jeweilige App das Feature unterstützt.

Das führt leicht zu Verwirrung:

• Registriert Ihr Euch auf dem Handy? Liegt der Passkey meistens dort oder in der Cloud des Handy-Herstellers.
• Loggt Ihr Euch auf dem Laptop ein? Kann ein anderer Passkey gespeichert werden.
• Nutzt Ihr mehrere Browser? Kann jeder seine eigene Speicherung haben.

Viele Nutzer stellen sich nach ein paar Monaten die Frage:

„Moment mal – habe ich meinen Passkey jetzt bei Google, Apple oder nur lokal auf dem Gerät?“

Wichtig: Es gibt bislang keinen einheitlichen, leicht verständlichen Standard, der immer anzeigt, wo der Passkey gespeichert wird und wie man ihn exportiert. Manche Dienste zeigen zwar den registrierten Authenticator an („iPhone von Max“ oder „YubiKey“), aber nicht jeder erklärt das so transparent.

Tipp:
Behalte immer im Blick:

• Welches Gerät Ihr benutzt habt, als Ihr den Passkey erstellt habt.
• Ob Ihr einen Cloud-Speicher aktiviert hattet (iCloud, Google, Microsoft).
• Ob Ihr mehrere Geräte oder Backup-Methoden registriert habt.

So vermeidet Ihr später unangenehme Überraschungen, wenn Ihr ein Gerät verliert oder wechseln wollt.

So vermeidet Ihr Vendor Lock-in und Verwirrung

Wenn Ihr Passkeys nutzen wollt, ohne Euch an Apple, Google oder Microsoft zu binden, könnt Ihr auf einen Hardware Key a la Yubikey oder auf unabhängige Passwortmanager setzen. Online-Lösungen wie Bitwarden, 1Password oder Proton Pass bieten mittlerweile Unterstützung für Passkeys an – und helfen Euch, den Überblick zu behalten.

Vorteile dieser Strategie:

Zentrale Verwaltung
Alle Passkeys liegen in einem einzigen Tresor, statt verstreut in iCloud, Google Password Manager oder Windows Hello. Ihr seht jederzeit, welche Schlüssel Ihr angelegt habt.

Plattformunabhängigkeit
Egal ob Windows, macOS, Linux, Android oder iOS – Ihr könnt Deine Passkeys überall nutzen, ohne an einen Hersteller gebunden zu sein.

Browser-Erweiterungen
Fast alle modernen Passwortmanager haben Erweiterungen für:

• Chrome
• Firefox
• Edge
• Safari
• Brave
• Vivaldi

Damit könnt Ihr Passkeys direkt beim Login vom Hardwarekey oder vom Browser Plugin automatisch ausfüllen und verwalten.

Apps für alle Geräte
Ob Smartphone, Tablet oder Desktop-PC: Ihr könnt Eure Passkeys komfortabel in der jeweiligen App abrufen, sichern und synchronisieren.

Synchronisation mit Zero-Knowledge-Prinzip
Seriöse Anbieter verschlüsseln alle Daten clientseitig, bevor sie synchronisiert werden. So kann der Betreiber (z.B. Bitwarden oder Proton) Eure Passkeys nicht sehen.

Beispielablauf:

1. Ihr erstellt einen Passkey über Euren Passwortmanager oder die Yubikey App, statt über den Browser oder das Betriebssystem.
2. Der Manager speichert den privaten Schlüssel in Eurem verschlüsselten Tresor.
3. Beim Login erkennt die Browser-Erweiterung, dass ein Passkey benötigt wird, und bietet automatisch die Anmeldung an.
4. Bei Bedarf synchronisiert Ihr den Tresor auf andere Geräte – unabhängig von Apple-ID oder Google-Konto.

Warum ist das sinnvoll?

• Ihr vermeidet Vendor Lock-in: Kein Zwang zur Nutzung von iCloud oder Google.
• Ihr könnt alle Passkeys einheitlich verwalten – auch zusammen mit klassischen Passwörtern und 2FA-Codes.
• Ihr seht transparent, wo was gespeichert ist.
• Ihr könnt Eure Passkeys leichter sichern, exportieren oder notfalls löschen.

Kurz gesagt:
Der Hardwareschlüssel oder ein moderner Passwortmanager wird zur Schaltzentrale Eurer Online-Identitäten. Ihr reduziert Verwirrung, behaltet die volle Kontrolle und müsst Euch nicht auf einen einzelnen Tech-Konzern verlassen der Euch nicht erlaubt, Eure Passkeys auf anderen Plattformen zu nutzen.

Worauf sollte man weiter achten

Auch wenn Passkeys viele Probleme klassischer Passwörter lösen, gibt es weitere wichtige Punkte, die Ihr bedenken solltet:

Backup und Wiederherstellung

• Verliert Ihr Euer Gerät, oder Zugang zum Passwort Manager, verliert Ihr die privaten Schlüssel.
• Viele Plattformen bieten Synchronisation in der Cloud (Apple iCloud Keychain, Google Password Manager), was aber die angesprochenen Risiken birgt.
• Alternativ könnt Ihr mehrere Geräte registrieren oder einen FIDO2-Token als Backup hinterlegen.

Tipp: Immer mindestens zwei Passkeys bzw. Geräte registrieren!

Kompatibilität

• Nicht jeder Dienst unterstützt Passkeys.
• Auch nicht jedes Gerät kann Passkeys speichern oder signieren.

Fazit

Passkeys sind ein enormer Fortschritt im Bereich Authentifizierung: sicherer, bequemer, moderner.
Aber sie sind nicht neutral: Die Art, wie sie implementiert werden, spielt Konzernen wie Apple, Google oder Microsoft in die Hände, indem sie Nutzer in die eigenen Dienste hineinziehen und dort halten.

Wichtige Empfehlungen:

1. Nutzt Passkeys mit Bedacht.
2. Registriert mehrere Geräte.
3. Bevorzuge Hardware-Token, wenn Euch Unabhängigkeit wichtig ist.
4. Informiert Euch, wo Eure Schlüssel gespeichert werden und ob Ihr sie exportieren könnt.
5. Erstelle Notfallpläne für den Verlust Eures Geräte.
6. Benutzt immer den selben Passwortmanager (z.B Bitwarden)

The post Passkeys - Vor und Nachteile appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

BalenaEtcher (früher einfach „Etcher“ genannt) ist ein Open-Source-Programm, mit dem sich Betriebssystem-Images unkompliziert auf SD-Karten, USB-Sticks und andere Speichermedien schreiben lassen. Die Software erschien vor über zehn Jahren, als das Unternehmen noch Resin hieß, und wurde 2018 zusammen mit der Umbenennung der Firma in balena ebenfalls umbenannt.

Ziel war von Anfang an, eine simple und plattformübergreifende Lösung zu schaffen, um bootfähige Datenträger zu erzeugen – insbesondere für Raspberry Pi und andere Embedded-Geräte. Das Programm ist bis heute wegen seiner klaren Benutzeroberfläche und der zuverlässigen Funktion sehr beliebt.

balenaEtcher im Vergleich zu Raspberry Pi Imager & Co.

Wenn Ihr balenaEtcher mit dem Raspberry Pi Imager oder anderen Tools wie Win32 Disk Imager oder dd vergleicht, fallen ein paar Punkte sofort auf:

Benutzerfreundlichkeit

balenaEtcher ist wirklich von Anfang an so gestaltet worden, dass absolut jeder – auch ohne Vorkenntnisse – ein Image auf eine Karte oder einen Stick schreiben kann. Die Oberfläche ist extrem reduziert:

1. Image-Datei auswählen
2. Ziel-Laufwerk auswählen (integrierte Schutzfunktion damit man sein eigenes Systemlaufwerk nicht überspielt)
3. Flashen klicken
   Fertig.
   
   Keine versteckten Optionen, keine komplizierten Pfade.

Der Raspberry Pi Imager hat zwar auch ein simples Design, ist aber stärker auf Raspbian (heute Raspberry Pi OS) ausgelegt und bringt direkt eine Vorauswahl von offiziellen Images mit. Wenn du andere Systeme flashen willst (Ubuntu, LibreELEC, exotische Images), ist balenaEtcher oft flexibler.

Win32 Disk Imager dagegen wirkt eher wie ein klassisches Windows-Tool – funktional, aber nicht gerade schön oder narrensicher. Für Linux-Anfänger ist es weniger intuitiv.

Und dd (unter Linux) ist zwar mächtig, aber definitiv nichts für Einsteiger:

sudo dd if=raspbian.img of=/dev/sdX bs=4M

Ein falscher Buchstabe – und Eure Festplatte ist futsch.

Plattformübergreifend

balenaEtcher läuft gleich gut auf Windows, macOS und Linux, ohne dass man herumfrickeln muss. Der Raspberry Pi Imager deckt auch alle drei Plattformen ab, ist aber manchmal etwas hakelig, z.B. bei älteren Linux-Distributionen.

Für Einsteiger gemacht

Gerade wer das erste Mal ein Image flashen will, fährt mit balenaEtcher am besten:

• kein Terminal
• keine kryptischen Optionen
• klare Statusanzeigen
• automatische Validierung (prüft, ob das Image korrekt geschrieben wurde)

Das gibt vor allem Anfängern Sicherheit – man sieht auf einen Blick, ob alles funktioniert hat.

BalenaEtcher und der Vorwurf des Datentrackings

Schon früh begann Balena, anonyme Telemetriedaten aus Etcher zu sammeln. Hintergrund war, dass die Qualität und Zuverlässigkeit von SD-Karten damals extrem schwankte und man auf diese Weise wertvolle Informationen über Fehlerursachen und Kompatibilität gewinnen wollte.

Auch wenn die Daten tatsächlich zur Weiterentwicklung beitrugen – etwa um Probleme mit Dateisystemen zu erkennen oder alte Linux-Distributionen nicht mehr zu unterstützen – sorgte die Datenerhebung bei vielen Nutzern für Kritik und Skepsis. Zwar konnte man in den Einstellungen jederzeit deaktivieren, dass Nutzungsdaten geteilt wurden, doch vielen war das nicht transparent oder konsequent genug.

Nun hat Balena ein klares Zeichen gesetzt: Ab Version 2.1.2 ist sämtlicher Analytics-Code aus balenaEtcher entfernt. Lediglich anonyme Absturzberichte können – wenn man möchte – weiterhin geteilt werden, worauf das Programm beim ersten Start nun deutlich hinweist.

Damit reagiert Balena auf die lange bestehenden Vorwürfe und unterstreicht, dass man die eigenen Werte – Enablement, Openness, Transparency, Reliability und First Principles Thinking – wieder stärker in den Mittelpunkt stellen will.

Wer Etcher also aus Sorge um die Privatsphäre gemieden hat, kann die aktuelle Version bedenkenlos nutzen: Es werden nun keine Daten mehr getrackt.

Balena Etcher könnt ihr hier auf Github downloaden:

https://github.com/balena-io/etcher/releases

The post Balena Etcher jetzt ohne Spyware appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Projekt orientiert sich konzeptionell an dem bekannten LightningTipBot für Telegram, erweitert es aber für den Einsatz auf Matrix, einer dezentralen Kommunikationsplattform. Die ursprüngliche Initiative stammt von @AE9999, der den Grundstein gelegt hat. Die Arbeit wurde aber von ursprünglichen Entwickler nicht mehr fortgesetzt und hat auch nicht mehr zuverlässig funktioniert. Meine Arbeit besteht darin, den Bot aktiv weiterzuentwickeln, zu warten und um neue Features zu ergänzen.

Das Projekt befindet sich nach wie vor im Beta-Stadium. Deshalb gilt der ausdrückliche Hinweis: Nutzer sollten nur so viele Mittel einzahlen, wie sie auch bereit sind zu verlieren. Falls ihr Lust habt, könnt ihr den Bot gerne auf unserem Matrix Server ausprobieren! Wer selber hosten will, und nen eigenen Matrix und LNBits Server betreibt, der kann der Anleitung unten folgen!

Github Repository erkunden

Zuerst könnt ihr mein Github Repo erkunden und euch mal durchsehen was der Bot so macht. Der Bot ist Open Source und funktioniert zusammen mit Matrix-Synapse und LNBits als Lightning Accounting System.

https://github.com/warioishere/matrix-lightning-tip-bot

Nutzungsmöglichkeiten

Der Bot kann auf zwei Weisen verwendet werden:

1. Direkt über unsere gehostete Instanz
   Unter der Matrix Account Adresse @lightning-wallet-bot:matrix.yourdevice.ch steht eine öffentlich zugängliche MLTB-Instanz zur Verfügung. Interessierte Nutzer laden den Bot einfach in einen Matrix-Raum ein. Nach dem Beitritt präsentiert der Bot sofort eine Übersicht der verfügbaren Befehle.
2. Eigenes Hosting
   Für mehr Kontrolle über den Bot und die angebundenen Lightning-Wallets können Betreiber MLTB selbst hosten. Dafür wird eine eigene LNbits-Instanz benötigt, die die User-API (/users/api/v1/user) bereitstellt. Auf LNBits muss natürlich ein Lightning Backend eingerichtet sein.

Unterstützte Befehle

Der Funktionsumfang ist bereits jetzt bemerkenswert breit. Zu den wichtigsten Kommandos gehören:

• !help – Lies diese Hilfe: !help
• !help-boltz-swaps – Erfahre, wie Swaps und Rückerstattungen funktionieren: !help-boltz-swaps
• !tip – Auf eine Nachricht antworten, um zu tippen: !tip <Betrag> [<Notiz>]
• !generate-ln-address – Erzeuge deine eigene LN-Adresse: !generate-ln-address <dein Adressname>
• !show-ln-addresses – Zeige deine erzeugten LN-Adressen: !show-ln-addresses
• !balance – Prüfe dein Guthaben: !balance
• !send – Sende Guthaben an einen Nutzer: !send <Betrag> <@Benutzer> oder <@Benutzer:domain.com> oder <[email protected]> [<Notiz>]
• !invoice – Erhalte Zahlungen über Lightning: !invoice <Betrag> [<Notiz>]
• !pay – Bezahle eine Lightning-Rechnung: !pay <Rechnung>
• !transactions – Liste deine Transaktionen auf: !transactions
• !link-to-zeus-wallet – Verbinde dein Wallet in Zeus: !link-to-zeus-wallet
• !donate – Spende an das matrix-lightning-tip-bot Projekt: !donate <Betrag>
• !party – Starte eine Party: !party
• !fiat-to-sats – Wandle Fiat in Satoshis um: !fiat-to-sats <Betrag> <Währung (USD, EUR, CHF)>
• !sats-to-fiat – Wandle Satoshis in Fiat um: !sats-to-fiat <Betrag> <Währung (USD, EUR, CHF)>
• !boltz-onchain-to-offchain – Tausche Onchain-BTC in Lightning: !boltz-onchain-to-offchain <Betrag> <Refund-Adresse>
• !boltz-offchain-to-onchain – Tausche Lightning in Onchain-BTC: !boltz-offchain-to-onchain <Betrag> <Onchain-Adresse>
• !refund – Erstatte einen fehlgeschlagenen Swap: !refund <swap_id>
• !version – Zeigt die Version dieses Bots an: !version

In privaten Direktnachrichten können alle Befehle ohne führendes ! eingegeben werden.

Einrichtung einer eigenen Instanz

Wer MLTB selbst betreiben möchte, findet eine detaillierte Schritt-für-Schritt-Anleitung:

Ladet das Repo in einen Ordner eurer Wahl herunter. Es empfiehlt sich für Programme immer einen eigenständigen Nutzer zu verwenden und nicht als root zu arbeiten.

1. Vorbereitung
   • Auf die aktuelle LNbits-Version (≥1.0.0) Upgraden. Das Plugin Usermanager wird nicht mehr benötigt.
   • openjdk-17-jdk und libsqlite3-dev auf dem Server bereitstellen.
2. Benutzer anlegen
   • Neuen Benutzer in LNbits anlegen, der Wallets verwaltet.
   • Die User-API muss aktiviert sein.
   • LNDHub aktivieren, um Wallets in Zeus zu verknüpfen.
   • X-Api-Key und Bearer Token kopieren.
3. Docker-Image bauen
   • Docker installieren.
   • Image mit ./gradlew buildDocker erstellen.
4. Lokale SQLite-Datenbank generieren
   • Rust installieren.
   • diesel_cli für SQLite mit cargo install diesel_cli --no-default-features --features sqlite installieren.
   • Datenbank via diesel migration run erzeugen.
5. Matrix-Account für den Bot
   • Auf dem Matrix-Server einen dedizierten Benutzer erstellen.
6. Konfigurationsdatei erstellen (config.conf)
   Die Konfiguration umfasst:

--matrix-server=https://matrix.my-matrixserver.org
--matrix-username=bot-user
--matrix-password=geheim
--lnbits-url=https://meine-lnbits.com
--lnbits-bearer-token=<BEARER-TOKEN>
--lnbits-api-key=<API-KEY>
--database-url=/data/db/tipbot.db
--allowed-matrix-server=https://matrix.my-matrixserver.org

Container starten
Beispiel:

docker run -d \
  --name matrix-tipbot \
  --restart always \
  -v /opt/lntipbot/data/config/config.conf:/data/config/config.conf \
  -v /opt/lntipbot/data/db/tipbot.db:/data/db/tipbot.db \
  matrix-lightning-tip-bot matrix-lightning-tip-bot @/data/config/config.conf

Alternativ lässt sich ein docker-compose Setup nutzen. Hierzu wird eine .env-Datei benötigt, die die relevanten Verzeichnisse definiert.

Geplante Weiterentwicklungen (TODOs)

Einige wichtige Meilensteine sind bereits erfolgreich umgesetzt worden, andere stehen noch an:

✅ Boltz Swaps direkt über den Bot laufen lassen um seine Wallet aufzuladen
✅ Unterstützung für eigene Lightning-Adressen per Befehl
✅ Information bei Bezahlung erstellter Rechnungen
✅ Einschränkung auf spezifische Matrix-Instanzen
✅ Benachrichtigungen bei Spenden
✅ Fiat-/Sats-Währungsumrechner
✅ Direktes Senden an Lightning-Adressen
✅ Transaktionsübersicht
✅ Anzeige der eigenen Lightning-Adresse
✅ Verknüpfung mit der Zeus-Wallet-App

Kontakt & Community

Für Support und Austausch gibt es einen öffentlichen Matrix-Raum:

https://matrix.to/#/#bitcoin:matrix.yourdevice.ch

BTC-Spenden sind ebenfalls willkommen. Die Lightning-Adresse lautet:

[email protected]

Fazit

Mit MLTB ist es mir gelungen, eine einfach nutzbare und flexible Lösung für Bitcoin-Lightning-Tipps in Matrix zu schaffen. Dank der Docker- und LNbits-Anbindung bleibt die Einrichtung trotz der Komplexität des Themas für technisch versierte Betreiber gut machbar. Das Projekt verfolgt konsequent das Ziel, Lightning-Zahlungen breiter nutzbar zu machen und nahtlos in dezentrale Kommunikationsplattformen zu integrieren.

Der Bot ist ein praktisches Werkzeug für Communities, die Wert auf digitale Souveränität und unkomplizierte Mikrozahlungen legen – und ein spannender Beleg dafür, wie Open-Source-Ökosysteme zusammenwachsen können.

The post Lightning TipBot und Wallet für Matrix appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

In diesem Beitrag zeigen wir Euch, wie Ihr unter Linux (Debian & Co.) und Windows Daten so sicher löschen könnt, dass sie selbst für einen erfahrenen IT-Forensiker entweder nicht mehr oder nur mit unverhältnismäßigem Aufwand wiederherstellbar sind – inklusive SSD-spezifischer Besonderheiten und Tools für ganze Laufwerke.

Warum normales Löschen keine echte Löschung ist

Viele glauben, dass eine Datei nach dem Löschen – ob per „Entf“-Taste, Papierkorb oder rm-Befehl – für immer verschwunden ist. Doch das ist ein gefährlicher Irrglaube.

Wenn Ihr eine Datei auf Eurem Computer löscht, passiert folgendes:
Das System entfernt nur den Verweis auf die Datei, also den Eintrag im Inhaltsverzeichnis der Festplatte (vergleichbar mit dem Entfernen eines Kapitels aus dem Inhaltsverzeichnis eines Buchs). Die eigentlichen Daten – also der „Text“ auf den Seiten – bleiben vollständig erhalten, bis sie durch etwas Neues überschrieben werden.

Das bedeutet:
Solange der Speicherbereich nicht mit neuen Daten überschrieben wurde, kann er mit frei zugänglicher Software (wie z. B. PhotoRec, Recuva oder TestDisk) problemlos wiederhergestellt werden. Und das selbst Wochen oder Monate später.

Ein Beispiel:
Stellt Euch vor, Ihr reißt ein Etikett von einem Aktenordner ab – der Ordner selbst und alle Dokumente darin bleiben aber im Regal stehen. Jeder, der weiß, wo er suchen muss, kann den Ordner öffnen und alles lesen.

Je nach Dateisystem (z. B. NTFS, ext4, APFS) und Speichermedium (HDD oder SSD) gibt es sogar Situationen, in denen selbst nach mehrfacher Formatierung noch Datenfragmente erhalten bleiben – besonders kritisch bei alten Festplatten, externen Speichersticks oder beim Verkauf gebrauchter Geräte.

Normales Löschen entfernt nur die Oberfläche – nicht den Inhalt. Wer sensible Daten wirklich vernichten will, muss sie gezielt überschreiben oder physisch zerstören. Alles andere ist bloß Kosmetik.

Sicheres löschen für Linux Debian basierte Systeme

1. Einzelne Dateien sicher löschen

Normales Löschen (rm datei.txt) entfernt nur die Dateireferenz – die Daten bleiben auf der Platte.

Lösung: shred

shred -u -z -n 3 datei.txt

-u: Löscht die Datei nach dem Überschreiben.

-z: Überschreibt am Ende mit Nullen (macht das Ergebnis "sauberer").

-n 3: Überschreibt 3-mal (Ich empfehle mind. 3 Durchgänge).

❗ Funktioniert nur auf Dateisystemen, die Überschreiben wirklich durchführen (z. B. ext3, ext4 ohne Journaling). Auf SSDs und journalenden Systemen (Btrfs, ZFS) nicht verlässlich!

Alternative: wipe oder secure-delete

sudo apt install secure-delete

danach löschen mit:

srm -vz datei.txt

2. Freien Speicherplatz sicher überschreiben

Das hilft, gelöschte Dateien nachträglich unlesbar zu machen.

sudo apt install secure-delete

Danach ordnerweise mit:

sfill -v /home

3. Ganze Partitionen oder Laufwerke sicher löschen

Lösung: dd mit Zufallsdaten

sudo dd if=/dev/urandom of=/dev/sdX bs=4M status=progress

• Achtung: Ersetzt ALLES auf der Zielplatte /dev/sdX.

❗ SSDs: Das funktioniert nicht verlässlich, da der Controller Daten selbstständig neu verteilt (Wear Leveling). Stattdessen:

4. SSDs sicher löschen (Linux)

Lösung: nvme oder hdparm

sudo hdparm --user-master u --security-set-pass Eins /dev/sdX
sudo hdparm --security-erase Eins /dev/sdX

Bei NVMe SSD's:

sudo nvme format /dev/nvme0n1 --ses=1

⚠️ Diese Befehle führen einen Secure Erase durch, der vom Controller der SSD unterstützt werden muss.

Sicheres Löschen von Daten unter Windows

1. Einzelne Dateien sicher löschen

Lösung: Eraser (GUI)

Kostenloses Open-Source-Tool:
https://eraser.heidi.ie/

• Unterstützt DoD 5220.22-M, Gutmann usw.
• Recht einfach zu bedienen.
• Kontextmenü-Einbindung im Explorer.

Alternativ per Kommandozeile:

cipher /w:C:

Das überschreibt freien Speicher auf Laufwerk C:. Bestehende Dateien bleiben erhalten!

2. SSDs unter Windows sicher löschen

Die meisten SSD-Hersteller bieten eigene Tools welche in den allermeisten Fällen zu bevorzugen sind. Billig SSD Hersteller wie Intenso bieten keine solcher Tools an. Diese Tools führen Erase Befehle durch, die technisch von der SSD direkt unterstützt werden:

• Samsung Magician
• Crucial Storage Executive
• SanDisk Dashboard
• Intel SSD Toolbox

Diese Tools führen Firmware-gesteuerte Secure-Erase-Befehle durch – ideal für SSDs.

3. Ganze Festplatte sicher löschen

Vor dem Weiterverkauf oder der Entsorgung:

Lösung: DBAN (Darik's Boot and Nuke)

• Bootfähiges ISO: https://dban.org/
• Überschreibt ganze Platten mehrfach
• ACHTUNG: Funktioniert nicht zuverlässig bei SSDs!

4. Für SSDs: Parted Magic

• Kommerzielle Linux-Distribution mit Secure-Erase-Unterstützung
• Unterstützt ATA Secure Erase & NVMe Format
• https://partedmagic.com/

Was man NICHT tun sollte:

• Nur rm, del, Papierkorb oder einfache bzw. schnelle Formatierungen verwenden → leicht wiederherstellbar
• „Schnellformatieren“ (Windows) → entfernt nur Dateitabelle
• SSDs mit dd oder shred behandeln → ineffektiv wegen Wear Leveling