Lebensmittel retten – aber nur mit App?

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

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

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

Die App-Pflicht als Eintrittskarte zum Essen

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

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

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

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

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

Digitale Selbstbestimmung ist kein Luxusproblem

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

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

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

Das ist digitale Ausgrenzung.

Nachhaltigkeit darf nicht selektiv sein

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

ein modernes Smartphone besitzen,

proprietäre Apps akzeptieren,

Tracking und Abhängigkeiten hinnehmen,

dann ist das keine soziale Nachhaltigkeit, sondern digitale Selektion.

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

Tafeln arbeiten am Limit.

Lebensmittelarmut nimmt zu.

Gleichzeitig werden Zugänge verengt, statt erweitert.

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

App-Zwang ist kein Naturgesetz

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

Reservieren

Abholen

Anzeigen
alles problemlos im Browser möglich.

Doch genau das wird verweigert.

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

Aber das ist ein Unternehmensinteresse, kein Gemeinwohl.

Digitalministerium, EU-Wallets und der falsche Weg

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

digitale Identitäten

Wallets

App-basierte Zugänge zu immer mehr Lebensbereichen

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

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

Warum ich darüber öffentlich schreibe

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

Die Antwort war eindeutig: Nein.

Deshalb mache ich das öffentlich.

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

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

Haltung statt Hormon

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

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

Was bei Hetzner, DNS und YunoHost wirklich passiert ist

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

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

1. Die Ausgangslage

Mein Setup:

Hetzner VPS

YunHost

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

automatische Let’s-Encrypt-Zertifikate

DNS bisher über die alte Hetzner DNS-Konsole

Hetzner hat angekündigt:

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

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

2. Das sichtbare Problem (Symptome)

Folgende Dinge traten gleichzeitig auf:

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

HSTS-Fehler

keine Möglichkeit, eine Ausnahme hinzuzufügen

Server YunHost meldet:

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

Zertifikate lassen sich nicht erneuern

Mastodon:

Föderation instabil

Verbindungsprobleme

dig zeigt:

intern: 1000.0.0.1

extern: andere IPs als erwartet

👉 Klassisches Zeichen für inkonsistente DNS-Quellen.

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

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

Das bedeutet:

Browser dürfen nur HTTPS

abgelaufene oder falsche Zertifikate = kompletter Zugriff gesperrt

kein „Ich vertraue trotzdem“-Button

💡 Das ist kein Bug – das ist Sicherheit.

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

Kette geschlossen. Ende.

4. Der entscheidende Hinweis: Zwei DNS-Welten gleichzeitig

Was wirklich passiert ist:

Alte Hetzner DNS-Konsole existiert noch

Neue Hetzner Console existiert schon

Domains sind teilweise migriert

Teilweise zeigen Records noch auf alte IPs

Teilweise schon auf neue IPs

Ergebnis:

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

Das ist der Worst Case für:

Zertifikate

Mail

Föderation (Mastodon und weitere Anwendungen)

Admin-Portale

5. Warum Hetzner-Support mir nicht helfen konnte

Ich habe:

ein Ticket eröffnet

telefonisch nachgefragt

Antwort (ehrlich & wichtig):

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

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

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

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

Das funktioniert kurzfristig.

❌ Aber:

DNS bleibt falsch

Zertifikate brechen beim nächsten Renew

Mail bleibt fehleranfällig

Mastodon und weitere Programme bleiben instabil.

Das ist Flickschusterei – keine Lösung.

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

👉 Entscheiden:

Entweder neue Hetzner Console

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

❌ Nicht beides gleichzeitig

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

Schritt 2: Alle A / AAAA Records korrekt setzen

Für jede Domain & Subdomain:

A → 1000.200.100.10

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

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

Schritt 3: Wildcards & Mail sauber nachziehen

* A / AAAA setzen

MX setzen

SPF / DKIM / DMARC aktualisieren

CAA für Let’s Encrypt setzen

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

Schritt 4: Warten (leider ja)

DNS braucht:

Minuten bis Stunden

manchmal 24–48 Stunden

Erst danach:

Zertifikate erneuern

Dienste testen

Mastodon stabilisieren

8. Warum jetzt plötzlich wieder manches geht

Du hast es selbst beobachtet:

Zertifikat für example.org geht wieder

Admin-Panel über ddd.example.org funktioniert

Probleme treten nur über das Portal / SSO auf

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

9. Fazit

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

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

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

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

Markus Lanz, Datenkontrolle und die neue EU-Überwachungsära – warum ich diesem System meine Freiheit nicht mehr anvertraue

Es gibt Momente, in denen man eine Talkshow einschaltet – und sich fragt, ob man eigentlich im falschen Film gelandet ist. Oder wie immer oder zu erwarten bei den Mainstream-Medien, die nicht sauber analysiert ihre Shows dem Bürger anbieten, durch ihre Zwangsgebühren.
So ging es mir wieder einmal bei Markus Lanz.

Da sitzen Politiker, Journalisten, Digitalstrategen – und reden über Digitalisierung, Cloud, Bürgervertrauen und technologische Zukunft.
Doch keiner von ihnen versteht, was wirklich auf dem Spiel steht:

Die Freiheit des Bürgers.
Die Unabhängigkeit seiner Daten.
Die Identität eines ganzen Landes.

🎭 Fernsehen als Kulisse – Realität als Kontrollsystem

Was bei Lanz diskutiert wird, ist weit entfernt von der Realität, in der Millionen Bürger leben.
Während der Talkshow-Olymp über Zukunft fabuliert, kämpfen Menschen mit Jobcentern, Behörden, übergriffiger Digitalisierung und einem Staat, der längst vergessen hat, wem er dienen soll.

Ich saß vor dem Bildschirm und dachte:
„Ihr redet von Fortschritt – ich sehe Überwachung.“

💣 Die Wahrheit über Hamburg, München und die Open-Source-Lüge

München hat einst LiMux gehabt – ein Vorzeigeprojekt, Open Source, Unabhängigkeit, echte Bürgernähe.
Dann wurde es eingestampft.

Warum?
Weil Microsoft mit Milliarden winkte.

Bayern bekam ein neues Microsoft-Zentrum und Söder klopfte sich stolz auf die Schulter.

Hamburg ging den mutigen Weg:
Open Source.
Kontrolle über die eigene Infrastruktur.
Unabhängigkeit von US-Konzernen.

Doch Lanz?
Kein Wort dazu.
Brücker?
Kein kritischer Ansatz.

🏢 Schwarz-Gruppe / LIDL baut eine Cloud – und keiner fragt nach den Konsequenzen

Eine Cloud ist nicht einfach ein Datenspeicher.
Eine Cloud ist ein Machtinstrument.

Sie bedeutet:

Docker-Container

APIs

Backdoors

staatliche Zugriffsrechte

Nutzungsprofile

Verhaltensanalyse

Wenn ein Konzern eine Cloud baut, geht es nicht um „Technik“.
Es geht um Kontrolle.

Und genau deshalb werden Konzerne wie Lidl und Aldi alles tun, um Datenströme zu sichern – aber niemals Systeme wie CREO unterstützen, die echte Privatsphäre ermöglichen.

🏦 Frankfurt wird zum Überwachungszentrum Europas

Mit AMLA baut die EU in Frankfurt eine Superbehörde der Finanzkontrolle.
Geldwäschebekämpfung ist nur das Etikett.
In Wahrheit geht es darum:

totale Transparenz finanzieller Bewegungen,

Abschaffung von Bargeld,

Kontrolle durch Algorithmen,

Bürger als permanent Verdächtige.

Dazu kommen die Zollbefugnisse, Meldepflichten, die Bargeldbremse und die Infrastruktur zur Seriennummern-Nachverfolgung von Scheinen.

Bargeld ist bereits jetzt nicht mehr anonym.

🔗 https://netzpolitik.org/2025/bargeld-tracking-du-hast-ueberwachungsinstrumente-im-portemonnaie/

📉 Was Markus Lanz nicht versteht: Freiheit stirbt nicht schlagartig – sondern Datenpunkt für Datenpunkt

Während Lanz über Politik plaudert, entsteht in Europa:

eine Datenkontrollmaschine,

ein digitaler Überwachungsstaat,

ein System, das Freiheit als Risiko betrachtet.

Und die Bürger?

Sie sollen „vertrauen“.
So wie man Ursula von der Leyen vertraut hat, während sie per SMS milliardenschwere Deals verhandelte.

🛑 Ich sage: Nein.

Ich nutze Linux.
Ich flashe mein Handy.


Ich reduziere Abhängigkeiten.

Ich folge CREO, weil es das einzige Konzept ist, das den Menschen und nicht den Staat in den Mittelpunkt stellt.

Ich gebe meine Daten nicht her.
Ich lasse mich nicht katalogisieren.
Ich lasse mich nicht digital umerziehen.

🔥 Schlusswort

Wenn Digitalisierung zur Kontrolle wird,
wenn Cloud-Systeme zur Überwachung werden,
wenn Politik Vertrauen predigt, aber Kontrolle meint –

dann bleibt nur eines:

Eigenverantwortung, Offenheit, kritisches Denken und Systeme wie CREO, die digitale Würde wiederherstellen.

Ist dieser ehemalige AfD-Bürger jetzt der AfD-Guru-Gegner?“

Söders Microsoft-Milliarde – Der digitale Ausverkauf Bayerns

Die neue Datenhölle Europas – Warum die Cloud der Schwarz-Gruppe kein Heiligenschein ist, sondern ein leise tickender Überwachungsaltar

CREO: Bewegung, Technik – oder geschlossene Architektur? Update vom [26.10.2026]: Antwort von CREO erhalten

🔐 Open-Source verstehen – Teil 2: Wie man Software richtig prüft

(Digitale Signaturen, Checksums & Vertrauen – einfach erklärt)

Wer Open-Source nutzt – egal ob Debian, Ubuntu, postmarketOS, Fedora, Arch oder andere – arbeitet immer auch mit Paketen, also kleinen Software-Bausteinen.
Damit diese Pakete sicher sind und nicht manipuliert wurden, besitzt jedes seriöse Linux-System eingebaute Sicherheitsmechanismen, die wir in diesem Teil einfach erklären.

🧠 Warum muss man Pakete überhaupt prüfen?

Jedes Linux-Paket wird in der Regel digital signiert:
mit GPG / OpenPGP, einem kryptografischen Verfahren.

Die digitale Signatur stellt sicher, dass:

das Paket vom echten Entwickler stammt

es unterwegs nicht verändert wurde

die Quelle (Repository) authentisch ist

keine Schadsoftware eingeschleust wurde

Damit hat Linux von Haus aus einen höheren Sicherheitsstandard als Windows oder macOS – wenn man die Signaturhinweise beachtet.

🧩 Wie prüft man die Echtheit?
(Beispiele für Debian, Ubuntu & postmarketOS)

Es gibt viele Wege – aber alle basieren auf dem gleichen Prinzip:
Wurde die digitale Signatur erfolgreich geprüft oder nicht?

🔹 1. Paketlisten aktualisieren (und Warnungen ernst nehmen)

Beim Aktualisieren zeigt Debian/Ubuntu die Signaturen automatisch an:

sudo apt update

Wenn alles korrekt ist → läuft ohne Warnungen durch.

Wenn etwas nicht stimmt, erscheint:

W: GPG error: … The following signatures couldn’t be verified…

Das bedeutet:

❌ Die Echtheit des Repositorys kann nicht bestätigt werden
❌ Pakete könnten manipuliert sein
❌ Keine Updates installieren!

Solche Warnungen niemals ignorieren.

🔹 2. Wo speichert Debian die vertrauenswürdigen Schlüssel?

Die Schlüssel für alle Paketquellen liegen hier:

ls /etc/apt/trusted.gpg.d/

Dort befindet sich jeder Schlüssel, dem dein System vertraut.
Fehlt ein Schlüssel → kann APT Updates nicht verifizieren

🔹 3. Manuelle Prüfung bei Downloads (ISO, .deb, tar.xz)

Wenn du Software außerhalb eines Repos herunterlädst (z. B. GitHub, Gnome.org, KDE.org), findest du oft diese Dateien:

software.tar.xz (die Datei selbst)

software.tar.xz.asc (digitale Signatur)

software.tar.xz.sha256 (Hash-Prüfsumme)

Hash prüfen: sha256sum DATEI.iso

Ausgabe vergleichen → muss exakt übereinstimmen.

Signatur prüfen: gpg –verify DATEI.asc DATEI

Wenn korrekt signiert:

✔ „Good signature from …“

Wenn nicht:

❌ „BAD signature“ → Datei löschen, nicht benutzen.

🔹 4. postmarketOS / Alpine Linux (apk)

postmarketOS nutzt apk, ein extrem strenges und modernes Paket-System.
Die Schlüssel liegen hier: ls /etc/apk/keys/

Wenn bei dir apk update fehlschlägt, liegt es fast immer an:

fehlenden Schlüsseln

veralteten Schlüsseln

defekter Zeiteinstellung (sehr häufig!)

defekten Repository-Servern

🛡️ Warum diese Prüfungen so wichtig sind

Linux ist ein offenes System – und genau deshalb ist Transparenz so zentral.
Man ist nicht auf „Blindes Vertrauen in eine Firma“ angewiesen, sondern auf:

Kryptografie

Signaturen

Öffentliche Schlüssel

Offene Verfahren

Die größte Gefahr entsteht, wenn man Warnungen ignoriert wie:

„Signature could not be verified“

Darum gilt:

✔ Warnungen ernst nehmen
✔ Schlüssel prüfen
✔ Repositories im Blick behalten

So bleibt das System sicher – ganz egal ob Laptop, Server oder Smartphone.

💬 Fazit

Linux bietet eines der sichersten Paket-Systeme der Welt – aber es funktioniert nur richtig, wenn man ihm aufmerksam folgt.

Du musst kein Experte sein.
Du musst nur wissen, worauf du achten solltest:

Stimmen die Signaturen?

Gibt es Warnungen?

Kommt das Paket aus einer offiziellen Quelle?

Dann bist du auf der sicheren Seite.

🧠 Warum man Pakete prüfen sollte

🧠 Warum man Pakete prüfen sollte

(Und wie du dich vor manipulierten Updates schützt)

Wenn du Linux nutzt – egal ob Debian, Ubuntu, postmarketOS, Fedora oder andere Distributionen – installierst du Software immer als sogenannte Pakete:

.deb (Debian / Ubuntu)

.apk (postmarketOS / Alpine Linux)

.rpm (Fedora, Red Hat)

.tar.xz (Quellpakete, Releases auf GitHub usw.)

Damit du sicher sein kannst, dass diese Pakete echt sind, werden sie vom Entwickler oder vom Maintainer kryptografisch signiert – meistens mit GPG / OpenPGP.

Diese Signaturen stellen sicher, dass:

✔ das Paket vom richtigen Entwickler stammt
✔ es nicht manipuliert wurde (z. B. durch Malware)
✔ die Übertragung nicht abgefangen wurde

Das Prüfen von Signaturen gehört zu den wichtigsten Sicherheitsmechanismen im Linux-Universum.

🔍 Wie man die Echtheit prüft

(Beispiele für Debian, Ubuntu & postmarketOS)

Jede Linux-Distribution hat eigene Werkzeuge – aber die Prinzipien sind überall gleich.

🔹 1. Paketlisten aktualisieren (und Warnungen ernst nehmen)

Wenn du bei Debian/Ubuntu eingibst: sudo apt update

und du bekommst eine Warnung wie: W: GPG error: … The following signatures couldn’t be verified
dann heißt das:

❌ Die Signatur konnte nicht überprüft werden
❌ Das Paket ist möglicherweise unsicher
❌ Du solltest KEINE Updates installieren, bevor der Fehler behoben ist

Diese Warnungen NIE ignorieren – sie schützen dich vor manipulierten Repositories.

🔹 2. Vertrauenswürdige Schlüssel anzeigen

APT (Debian/Ubuntu) speichert alle Signaturen der Paketquellen hier: ls /etc/apt/trusted.gpg.d/

Jede Datei dort steht für einen Schlüssel, der für Updates vertraut wird.

Wenn hier ein Schlüssel fehlt → kann APT Updates nicht verifizieren.

🔹 3. Signatur manuell prüfen (z. B. bei Downloads von GitHub)

Wenn du ein .tar.xz oder .iso herunterlädst, findest du oft daneben:

eine Datei .asc (Signatur)

eine Datei .sha256 (Checksummen)

Du kannst damit prüfen:

🔸 Hash prüfen
sha256sum DATEI.iso

→ ergibt eine lange Zeichenkette
→ muss mit der Hersteller-SHA256 übereinstimmen

🔸 Signatur prüfen

gpg –verify DATEI.asc DATEI Wenn alles korrekt ist, erscheint:

✔ Good signature from “NAME DES ENTWICKLERS”

🔹 4. postmarketOS / Alpine Linux (apk-tools)

postmarketOS nutzt apk, nicht apt.

Du prüfst die Repository-Signaturen so:

Repository-Schlüssel anzeigen sudo apk policy
oder:
ls /etc/apk/keys/
Dort liegen die öffentlichen Schlüssel der Maintainer.

Wenn apk update bei dir sofort abbricht, kommt das meistens durch:

fehlende Schlüssel

beschädigte Schlüssel

falsche Zeitzone

falsches Datum des Systems

defekte Repository-Server

Das könnte gefixt werden, sobald du so weit bist.
Doch das würde in einem separaten Blogbeitrag erörtert werden.

🛡️ Warum das Prüfen so wichtig ist

In der Linux-Welt ist das Paket-System eines der sichersten der Welt.
Aber es hängt von dir ab, Warnungen ernst zu nehmen.

Wenn die Signatur nicht stimmt:

🚫 Kein Update installieren
🚫 Kein Paket anfassen
🚫 Repository überprüfen
🚫 Schlüssel aktualisieren

Nur so bleibt dein System wirklich sicher.

Und vor allem:

✔ Dein Server bei Hetzner oder sonstigen Hostern
✔ Dein Laptop
✔ Dein postmarketOS-Smartphone

sind dadurch besser geschützt als jedes Windows-System.

💡 Fazit
Das Prüfen von Paketen ist kein kompliziertes Hacker-Werkzeug, sondern ein eingebauter Schutzmechanismus in jeder Linux-Distribution.
Du brauchst nur:

die Warnungen zu verstehen

und angewöhnen, auf Signaturen zu achten

Dann kann dir fast nichts passieren.