Selbst betrieben statt eingekauft
Fehler-Tracking läuft auf einer selbst gehosteten GlitchTip-Instanz auf eigener Scaleway-Infrastruktur — Absturzberichte verlassen unsere Server nicht. Und sie enthalten dich nicht: Bevor ein Bericht rausgeht, werden Nutzer-Identität, IP, Cookies, Header, Authorization-Token, Request-Body und Query-String entfernt. Der Body ist der wichtige Teil davon — dort stünden sonst Notiz-Inhalte und Suchanfragen. Ablauf-Tracing ist standardmäßig aus. Die Besucherstatistik dieser Website ist cookielos (Plausible, EU) und in der App gibt es gar keine.
Schlüssel, die nur eines dürfen
Zugriffsschlüssel folgen dem Least-Privilege-Prinzip: Jedes System bekommt nur die Rechte, die es wirklich braucht. Beispiel: Der automatische Deploy dieser Website hält keinen account-weiten CDN-Schlüssel — nur ein Token, das genau eines kann: den Cache dieser Seiten leeren. Die zentralen Schlüssel selbst liegen im Secret Manager bei Scaleway, nicht in externen Build-Systemen.
Die Trennung liegt in der Datenbank, nicht im Code
Bei den meisten Diensten sorgt Anwendungscode dafür, dass du fremde Daten nicht siehst — ein vergessenes „where user = …“ in einer einzigen Abfrage reicht dann für ein Leck. Bei Memexa liegt die Trennung eine Ebene tiefer: PostgreSQL erzwingt sie über Row-Level Security. Ohne gesetzten Benutzerkontext gibt die Datenbank keine Zeilen heraus — nicht die falschen, sondern gar keine. Der Kontext wird pro Transaktion gesetzt und fällt beim Abschluss automatisch weg, kann also nicht auf die nächste Verbindung aus dem Pool überspringen. Damit das so bleibt, läuft im Testlauf eine Prüfung mit, die anschlägt, sobald eine neue Tabelle ohne Row-Level Security oder ohne ausdrückliche Einstufung dazukommt: Der Bau schlägt fehl, statt still durchzugehen.
Was deine KI darf, entscheidest du — und nimmst es zurück
Claude, ChatGPT und Cursor bekommen keinen Generalschlüssel. Der Zugang läuft über OAuth: Du siehst vor der Freigabe, welcher Client fragt und wohin der Zugriff geht, und bestätigst ihn selbst. Der Browser-Clipper und der volle KI-Zugriff haben dabei getrennte Berechtigungen — der Clipper darf ablegen, nicht deinen Bestand durchsuchen. Verbundene Clients kannst du jederzeit im Dashboard trennen; zusätzlich gibt es einen Widerrufs-Endpunkt nach RFC 7009 für Clients, die ihn von sich aus aufrufen. Und die Zugriffsprüfung hängt nicht an einer einzigen zentralen Stelle: Jede Schnittstelle prüft die Sitzung selbst, damit ein Fehler an einer Stelle nicht alles öffnet.
Löschen heißt löschen — in dieser Reihenfolge
Du kannst dein Konto selbst löschen, mit Bestätigung per E-Mail. Was dann passiert, ist bewusst herumgedreht: Zuerst werden alle Dateien im Objektspeicher entfernt — über den kompletten Nutzer-Präfix, also einschließlich verwaister Dateien, die zu keinem Eintrag mehr gehören. Erst danach fallen die Datenbankeinträge. Scheitert die Datei-Löschung, bricht der ganze Vorgang ab und dein Konto bleibt bestehen, statt dass die Verwaltungsdaten weg sind und die Dokumente liegen bleiben. Der Vorgang lässt sich gefahrlos wiederholen. Einzelne Inhalte kannst du jederzeit einzeln löschen, ohne das Konto anzufassen.
Die Leitungen dahin
Verschlüsselt ist jede Strecke: TLS 1.2 aufwärts an der Kante, ältere Versionen sind abgeschaltet; die Datenbankverbindungen laufen mit verify-full, also mit geprüftem Zertifikat und Hostnamen, nicht nur „irgendwie verschlüsselt“. Die Datenbank hängt in einem privaten Netz ohne öffentliche Adresse. Davor sitzen WAF und DDoS-Schutz, und der Ursprungsserver nimmt nur Anfragen aus dem Netz des CDN an — direkt kommt man nicht an ihn heran. Der Anwendungscontainer läuft ohne Root-Rechte, Abhängigkeiten werden aus einer festgeschriebenen Lockfile gebaut, und das eine externe Binärprogramm, das wir brauchen, ist auf Version und Prüfsumme festgenagelt. Staging und Produktion sind getrennte Projekte, nicht zwei Ordner im selben.