Ostler bewahrt Ihr gesamtes digitales Leben an einem Ort auf. Das ist gleichermaßen mächtig und gefährlich. Diese Seite erklärt genau, wie wir es schützen. Kein Drumherumreden, keine “branchenübliche Verschlüsselung.” Konkretes und ehrliche Statusangaben zu jeder Behauptung.
Das Bedrohungsmodell ist hier anders. Ein Einbruch in Ihr LinkedIn legt einen Ausschnitt Ihres Lebens offen. Ein Einbruch in Ostler würde alles offenlegen – jede Beziehung, jedes Gespräch, jedes Muster. Wir haben die Sicherheit um diese Realität herum aufgebaut.
Die realistische Bedrohung ist Software, keine magische KI. Was ein local-first-Produkt bedroht, ist bösartiger Code, der auf demselben Mac mit Ihren Berechtigungen läuft und Dinge tut, um die Sie nicht gebeten haben. Die KI in Ostler ist ein angewiesener Insider: eingegrenzte Tool-Aufrufe, eingegrenzter Datenzugriff, geprüfte Ausgaben. Der unerwartete Angreifer ist alles andere, das auf dem Host Fuß gefasst hat.
Ostler verbindet sich mit keinem externen Server. Kein Cloud-Backend. Kein API-Endpunkt. Keine Telemetrie. Die Datenbanken, die KI-Modelle und die Verarbeitungspipeline laufen alle auf Ihrem Mac.
Dies eliminiert die größte, langweiligste Klasse von Angriffsvektoren für persönliche Daten: Server-Einbrüche, Man-in-the-Middle-Angriffe, Credential Stuffing, Insider-Zugriff beim Anbieter und behördliche Datenanfragen gegen den Anbieter. Es gibt keinen Server, in den eingebrochen werden kann. Es gibt keine Daten, die angefordert werden können.
Überprüfen Sie es selbst. Trennen Sie die Internetverbindung. Alles funktioniert weiter.
Was dies nicht ist: eine Behauptung, dass nichts schiefgehen kann. Die Cloud zu entfernen schließt die Tür, durch die ein Angreifer am häufigsten geht. Es versiegelt nicht jedes Fenster. Die ehrlichen Grenzen – was in Ihrer Verantwortung bleibt – werden unten unter Wogegen dies keinen Schutz bietet dargelegt.
Es gibt kein Passwort. Wir haben Passwörter vollständig vom Tisch genommen.
Beim ersten Start registriert Ostler einen Passkey in der Secure Enclave Ihres Mac. Von diesem Moment an ist das Entsperren von Ostler eine Touch-ID-Berührung, ein Face-ID-Blick oder ein Doppelklick auf Ihrer Apple Watch. Der kryptografische Identitätsnachweis liegt im Hardware-Sicherheitschip Ihres Mac. Er kann nicht exportiert, abgephisht oder auf den Rechner eines Angreifers kopiert werden.
Creative Machines sieht niemals ein Passwort, weil es kein Passwort zu sehen gibt. Wir erhalten niemals ein Login-Token, ein Session-Cookie oder einen gehashten Zugangsnachweis. Es gibt nichts, was wir bei einem Einbruch verlieren könnten, weil wir nichts halten.
Ihr Passkey synchronisiert sich über den iCloud Keychain mit Ihren anderen Apple-Geräten, Ende-zu-Ende-verschlüsselt durch Apple. So wird die Ostler-iOS-App Daten desselben Hub ohne einen zweiten Einrichtungsschritt entsperren.
Das At-Rest-Design von Ostler gibt jeder Datenbank eine eigene Verschlüsselungsschicht unter einem 32-Byte-Datenverschlüsselungsschlüssel (DEK). Die FileVault-Vollverschlüsselung schützt heute alles auf dem Mac; die feiner abgestufte Schicht pro Datenspeicher ist in der Prüfung, und die Tabelle unten zeigt den ehrlichen Status pro Komponente. Der DEK wird bei der Installation auf Ihrem Mac erzeugt, verlässt Ihren Mac nie im Klartext und wird unter einem aus Ihrem Passkey abgeleiteten Schlüssel eingehüllt (verschlüsselt). Ostler zu entsperren bedeutet: Ihre Biometrie entsperrt den Passkey, der Passkey entpackt den DEK, der DEK entschlüsselt die Datenbanken. Wenn die App sperrt, wird der DEK aus dem Speicher gelöscht.
Ostler sperrt sich nach einem konfigurierbaren Zeitraum der Inaktivität automatisch. Beim Sperren wird der im Speicher gehaltene Verschlüsselungsschlüssel überschrieben. Ein gestohlener oder verlorener Mac auf dem Schreibtisch des Angreifers kann ohne eine live Touch ID / Face ID von Ihnen keinen Klartext preisgeben.
Die meiste Verbrauchersoftware modelliert Gerätediebstahl nicht ernsthaft – die Cloud hält die echte Kopie, also wird ein gestohlenes Gerät als verlorener Endpunkt behandelt. Wir modellieren ihn, weil hier das Gerät die Daten ist und die Daten intim sind. Es gibt keine Cloud-Kopie als Rückfalloption. Die automatische Sperre, das Löschen des Schlüssels aus dem Speicher und die Anforderung einer live Biometrie zum erneuten Entsperren sind um diese Realität herum entworfen, nicht nachträglich angeschraubt.
Es gibt keine Passwort-Zurücksetzen-E-Mail, keinen Magic Link, keine an E-Mail gebundene Wiederherstellung. Ein kompromittiertes Postfach kompromittiert nichts.
Ein gängiges Muster bei “passwortlosen” Produkten ist es, Authentifizierung oder Wiederherstellung an E-Mail zu binden – einen Magic Link, einen Einmalcode, einen Passwort-Reset-Ablauf. An der Oberfläche sieht es stark aus; es gibt kein Passwort zum Phishen. Der Haken ist, dass die Sicherheit des gesamten Systems die Sicherheit des E-Mail-Kontos des Nutzers erbt. Ein kompromittiertes Postfach ist eine kompromittierte Identität.
Ostler funktioniert nicht so. Es gibt keine Passwort-Reset-E-Mail, keinen Magic Link, keine E-Mail-gebundene Wiederherstellung für das lokale Produkt. Der data-encryption key wird vom Hub auf Ihrem Mac bei der Installation ausgestellt und unter einem aus Ihrem Passkey abgeleiteten Schlüssel gewrappt, der in der Secure Enclave Ihres Mac liegt. Die einzige Out-of-Band-Rückfalloption ist die 12-Wort-Phrase, die Sie aufgeschrieben haben. Die Lückenlosigkeit der Verwahrung läuft niemals über Ihr Postfach.
Es gibt genau eine Rückfalloption: eine 12-Wort-Wiederherstellungsphrase, die während der Einrichtung erzeugt wird. Sie schreiben sie auf Papier. Sie bewahren sie an einem sicheren Ort auf. Sie tippen sie niemals in iCloud, Dropbox, einen Passwortmanager oder ein Foto.
Die Phrase wird Ihnen einmal auf einem Bildschirm gezeigt, der Kopieren-und-Einfügen blockiert, und danach niemals auf der Festplatte gespeichert. Um konkret zu sein, was wir von BIP39 verwenden und was nicht: Wir verwenden seine 2048-Wort-Liste in englischer Sprache und seine Entropie-zu-Wörter-Kodierung (128 Bit Entropie plus eine 4-Bit-Prüfsumme ⇒ 12 Wörter). Wir implementieren nicht den PBKDF2-Mnemonic-to-Seed-Schritt von BIP39 – wir behandeln die Entropie direkt als unser Wiederherstellungsschlüssel-Material, was für ein Nicht-Wallet-System die richtige Wahl ist. Ostler ist kein Kryptowährungs-Wallet und wir beanspruchen keine BIP39-Wallet-Kompatibilität. Wir verwenden die Wortliste, weil sie öffentlich geprüft und ergonomisch bewährt ist, nicht weil wir mit irgendetwas interoperieren.
Wenn Sie Ihren Mac und Ihr iPhone verlieren und der iCloud Keychain Ihren Passkey nicht auf ein neues Gerät wiederhergestellt hat, ist die Wiederherstellungsphrase der Weg zurück hinein. Sie wickelt eine zweite, unabhängige Kopie desselben DEK aus.
Wenn Sie die Phrase und alle Ihre Apple-Geräte und Ihr Time-Machine-Backup gleichzeitig verlieren, sind Ihre Daten weg. Durch uns, durch jeden. Das ist der Preis echter Privatsphäre – dieselbe Architektur, die uns daran hindert, Ihre Daten zu lesen, hindert uns daran, Ihnen bei der Wiederherstellung zu helfen.
Ihre Daten sind durch mehrere Schichten geschützt. Jede Zeile unten zeigt den aktuellen, ehrlichen Status – nicht was wir beabsichtigen, sondern was tatsächlich im Build ist:
| Komponente | Verschlüsselung | Status |
|---|---|---|
| Gesamte Festplatte | macOS FileVault (AES-256-XTS) | Live Der Installer prüft, ob dies aktiviert ist |
| SQLite-Datenbanken | SQLCipher (AES-256) | Live im Code Die FileVault-Vollverschlüsselung schützt heute alles; die feiner abgestufte Schicht pro Datenspeicher ist gebaut und in der Prüfung |
| iOS-App-Secure-Store | Realm (AES-256), gerätegebundener Schlüssel | Live Stimmprofil-Speicher heute auf iOS verschlüsselt |
| iOS-App-Hauptspeicher | Passkey-abgeleiteter Realm-Schlüssel (mit Hub geteilt) | In Entwicklung Plattformübergreifende Spezifikation abgezeichnet; iOS-Pairing-Flow als Nächstes |
| Vektor- + Graph-Datenbanken | Verschlüsseltes APFS-Volume | Spezifiziert Design freigegeben; Build geplant nach dem SQLCipher-Härtungsdurchlauf. FileVault schützt diese Datenspeicher heute |
| Lokales Audit-Log | SQLCipher-verschlüsselt, append-only | Live im Code Per-Eintrag-HMAC-Integritätskette ist ein geplantes Upgrade |
| Time-Machine-Backups | Erbt FileVault | Live Über macOS-Time-Machine-Verschlüsselung |
Zwei Bestandteile von Ostler gelangen bei der Installation aus dem Internet auf Ihren Mac: die Assistent-Binärdatei selbst und die Gewichte des lokalen LLM-Modells. Wir behandeln die Integrität jedes Teils unterschiedlich, weil die Vertrauensform unterschiedlich ist.
Die Assistent-Binärdatei wird als signiertes Tarball mit einer in einer Sidecar-Datei veröffentlichten SHA-256-Prüfsumme ausgeliefert. Der Installer lädt beide herunter, berechnet den Hash des Tarballs und weigert sich fortzufahren, wenn die Werte nicht übereinstimmen. Manipulation zwischen unserer Release-Pipeline und Ihrem Mac – durch einen Vermittler, durch ein kompromittiertes CDN, durch irgendeinen Akteur dazwischen – ist ein harter Installationsfehler, keine stille Kompromittierung.
Die Modellgewichte stammen aus kuratierten Upstream-Registries (der Ollama-Registry, Hugging Face) über TLS zur Installationszeit. Wir pinnen Modellnamen; wir verlassen uns auf die Tag-Unveränderlichkeitsdisziplin des Upstream-Maintainers dafür, auf welche Bytes diese Namen auflösen. Wir sind ehrlich bezüglich der Vertrauensannahme: Wenn ein Maintainer eines Upstreams, von dem wir abhängen, ein bösartiges Update unter einem von uns gepinnten Tag ausliefern würde, würden frische Installationen es ziehen, bis der Upstream das Problem bemerkt. Wir pinnen Versionen, wo wir können, lesen Changelogs und halten die Modell-Oberfläche klein. Dies durch das Pinnen von Content-Digests weiter zu verschärfen, ist ein Härtungspunkt auf der Post-Launch-Liste.
Wenn die Ostler-iOS-App mit Ihrem Mac Hub kommuniziert, ist die Verbindung darauf ausgelegt, über TLS mit einem während der Installation erzeugten selbstsignierten Zertifikat zu laufen, wobei das iPhone den öffentlichen Schlüssel des Zertifikats beim Pairing pinnt, sodass nur Ihr Mac antworten kann.
Der kryptografische Vertrag – Pairing-QR-Code-Format, WebAuthn-Handshake, HMAC-basierter Nachweis des gemeinsamen Passkeys, zehnminütiges Ablaufen des Pairing-Tokens – ist in einer normativen plattformübergreifenden Spezifikation festgelegt, die am 23.04.2026 sowohl von den Hub-seitigen als auch von den iOS-seitigen Implementierern abgezeichnet wurde. Jede HKDF-Konstante, jedes Wire-Format-Byte und jeder Testvektor ist festgelegt. Hub-seitiges Code-Signing ist der verbleibende Blocker, bevor das iPhone-zu-Hub-Pairing Ende-zu-Ende läuft (siehe unten).
Alles bindet an localhost. Nichts ist von außerhalb Ihres Macs erreichbar, und kein Port wird je dem Internet ausgesetzt.
127.0.0.1 (nur Loopback); keiner akzeptiert LAN-Verbindungen. Dies schützt gegen jeden Angreifer, der nicht bereits auf Ihrem Mac ist. Es isoliert Ostler nicht von anderer Software, die auf demselben Mac wie Sie läuft – siehe unten.Die KI in Ostler ist ein angewiesener Insider, in der Formulierung des Hinweises oben auf dieser Seite. Dieser Abschnitt zeigt, was das konkret bedeutet: was der Assistent tun darf, was er nicht tun darf und wie seine Aktionen aufgezeichnet werden.
Workspace-Eingrenzung. Der Assistent liest und schreibt innerhalb eines standardmäßig verweigernden Workspace. Die Verzeichnisse, die Ihre Zugangsdaten und Ihre privaten Schlüssel enthalten – ~/.ssh, ~/.gnupg, ~/.aws, ~/.config, die Systemverzeichnisse unter /etc, /usr, /var – stehen auf einer statischen Sperrliste, die jedes dateiberührende Tool pfadbasiert absichert. Der Assistent kann Ihre Nachrichten, Ihre E-Mails und die Dokumente lesen, um deren Lektüre Sie ihn gebeten haben; er kann, selbst durch Missgeschick, nicht Ihren SSH-Schlüssel lesen.
Gehärtete Binärdatei. Die Assistent-Binärdatei ist mit aktivierter macOS Hardened Runtime gebaut, wobei die JIT-, Library-Injection- und dyld-Umgebungsvariablen-Fähigkeiten zur Code-Sign-Zeit verweigert werden. Die üblichen prozessebenen Injection-Pfade, die gegen gewöhnliche Mac-Software funktionieren – DYLD_INSERT_LIBRARIES-Hooks, JIT-gemappte Code-Injection, Loader-Umgebungsvariablen-Umschreibungen – funktionieren nicht gegen den Assistenten. Code-Signing-Vertrauen ist das Tor; nur die ursprüngliche Binärdatei läuft.
Tool-spezifisches Freigabe-Gate. Jeder Tool-Aufruf durchläuft ein Freigabe-Gate. Im Modus Überwacht (der Standard) blockiert ein Tool, das in dieser Sitzung nicht vorab freigegeben wurde, bis Sie ja sagen. Sitzungsbezogene Allowlists tun, was der Name sagt: Sie laufen ab, wenn die Sitzung endet, nicht wenn der Assistent entscheidet, dass er Ihr Vertrauen für immer verdient hat.
Kanalgesteuertes Default-Deny. Wenn der Assistent von einer eingehenden Nachricht gesteuert wird – iMessage, WhatsApp, E-Mail – gibt es keinen Menschen an der Tastatur, der einen Tool-Aufruf freigibt. In dieser Haltung kann der Assistent nicht fragen, also führt er kein Tool außerhalb einer kleinen schreibgeschützten Allowlist aus (Suche, Lookup, Abruf einer öffentlichen Webseite). Eine per Nachricht eintreffende Prompt-Injection kann nicht zu Dateischreibvorgängen, beliebigen Netzwerkaufrufen oder destruktiven Shell-Befehlen eskalieren; die Shell-Tool-Oberfläche in dieser Haltung ist durch eine separate vorab freigegebene Befehls-Allowlist eingegrenzt.
Manipulationssicheres Audit-Log. Jeder Tool-Aufruf schreibt einen Datensatz in ein lokales Audit-Log, das eine SHA-256-Hash-Kette verwendet: Jeder Eintrag enthält den Hash des vorherigen Eintrags, sodass ein gelöschter oder bearbeiteter Eintrag die Kette auf eine Weise bricht, die die Replay-Validierung erkennt. HMAC-Signierung jedes Eintrags wird als zusätzlicher Härtungsschritt unterstützt. Das Audit-Log ist lokal; es wird nirgendwohin verschickt.
Standardmäßig private Gespräche. Gespräche zwischen Ihnen und dem Assistenten werden auf Ihrem Hub gespeichert und standardmäßig als privat markiert. Inhalte, die auf der sensibelsten Datenschutzstufe markiert sind (vollständige Transkript-Inhalte, die Sie im Vertrauen geteilt haben), werden von Abfrageantworten zurückgehalten, es sei denn, der aufrufende Client entscheidet sich ausdrücklich dafür. Der Standard-API-Pfad gibt Metadaten zurück, keine Inhalte.
Ostler läuft als Ihr Benutzerkonto auf Ihrem Mac – nicht als root, nicht als Systemdienst. Der Orchestrator, das API-Gateway, die lokalen Datenbanken und die Inferenzprozesse laufen alle innerhalb des Berechtigungsumfangs Ihres Benutzers. Es gibt keinen LaunchDaemon, der mit dem Installer ausgeliefert wird, und keinen Hintergrundprozess, der das Abmelden überlebt.
Der Installer fragt einmal, zur Installationszeit, nach einem Administrator-Passwort, für die Operationen auf Systemebene, für die macOS Administratorrechte verlangt: das Ändern der Energieverwaltungseinstellungen, damit der Hub für Ihr iPhone erreichbar bleibt, wenn der Mac im Leerlauf ist (Ruhezustand im Netzbetrieb deaktivieren, Wake-on-Magic-Packet aktivieren), und das Installieren der unterstützenden Pakete (Homebrew, Ollama), die als Standard-macOS-CLIs ausgeliefert werden. Nach der Installation fragt kein Teil von Ostler nach erhöhten Berechtigungen zur Ausführung, und die Anwendung hat keinen Pfad, der von selbst eskaliert.
Dies begrenzt den Wirkungsradius eines Fehlers oder eines erfolgreichen Angriffs auf Ostler selbst: Er erbt die Reichweite Ihres Benutzers, nicht die des Systems. Es schützt nicht gegen Malware, die sich die Berechtigungen Ihres Benutzers bereits über einen anderen Vektor verschafft hat – das ist die Oberfläche, um die es im nächsten Abschnitt geht.
Die Cloud zu schließen, schließt die größte, langweiligste Klasse von Angriffen – die Art, die eine Million Menschen auf einmal offenlegt. Es bedeutet nicht, dass niemals etwas schiefgehen kann. Wir nennen Ihnen lieber die Grenzen, als Sie sie entdecken zu lassen.
Dies ist die realistische Bedrohungsoberfläche für ein local-first-Produkt, und wir sind diesbezüglich offen. Wenn ein Stück Malware Ihren Mac über eine bösartige Browser-Erweiterung, einen vergifteten Download oder eine kompromittierte App von außerhalb des App Store erreicht, erbt es die Fähigkeit Ihres Benutzers, mit localhost zu sprechen. Die Verschlüsselungsschicht im Ruhezustand schützt gegen physischen Diebstahl und gegen das Verlassen Ihrer Daten vom Gerät, aber sie isoliert Ostler nicht von anderer Software, der Sie die Erlaubnis zur Ausführung gegeben haben. Behandeln Sie Ihren Hub-Mac so, wie Sie einen Passwortmanager oder eine Banking-App behandeln würden: Installieren Sie keine beliebigen Hilfsprogramme, genehmigen Sie keine Installer-Aufforderungen, die Sie nicht selbst angestoßen haben, und verwenden Sie idealerweise einen Mac, der überwiegend Ostler und nicht viel anderes laufen lässt.
Ostler läuft auf Ollama, einer LLM-Modelldatei, einer Python-Laufzeitumgebung und einer kleinen Menge von Python-Paketen. Wir schreiben diese nicht, wir verwenden sie. Wenn eines dieser Upstream-Projekte morgen ein bösartiges Update auslieferte, wären frische Installationen – unsere, Ihre, die jedes anderen Nutzers – gefährdet, bis das Problem entdeckt würde. Wir pinnen Versionen, wir lesen Changelogs, wir halten die Abhängigkeitsoberfläche so klein wie möglich. Wir werden nicht so tun, als wäre das Risiko null. Derselbe Lieferketten-Vorbehalt gilt für jede Software, die Sie jemals irgendwo installieren.
Die Wiederherstellungsphrase ist die Worst-Case-Hintertür. Wenn Sie sie auf einen Klebezettel schreiben, ein Foto davon machen, sie in eine Cloud-Notizen-App einfügen oder sie in einem Videoanruf vorlesen, wird die Phrase zum kürzesten Pfad des Angreifers. Wir machen es einfach, das Richtige zu tun – der Bildschirm blockiert Kopieren-und-Einfügen, das Wiederherstellungsdokument erklärt die Bedrohung – aber das letzte Glied in der Kette sind Sie.
Dies ist der Preis eines Systems, das die Schlüssel auf Ihrer Hardware hält, nicht auf unserer. Wir können das Innere architektonisch gestalten; wir können schlechte operative Hygiene nicht weg-architektonieren. Die Minderung ist ehrliche Dokumentation, kein Versprechen, das wir an Ihrer Stelle halten können.
Wir binden erfahrene Sicherheitsberater ein und definieren den Umfang eines unabhängigen Sicherheitsaudits durch eine anerkannte Cybersicherheitsfirma. Der Umfang deckt Authentifizierung, Datenverarbeitung, Speicherverschlüsselung, Netzwerkhaltung und Abhängigkeitsanalyse ab. Der Bericht wird hier veröffentlicht, wenn er fertig ist.
Wir haben uns für ein professionelles Audit entschieden, statt uns auf Community-Code-Review zu verlassen, weil eine Expertenprüfung rigoroser ist, als zu hoffen, dass jemand den Code liest. Vertrauen sollte überprüfbar sein, nicht angenommen. “Wir versprechen, nicht auf Ihre Daten zu schauen” ist, was jedes Cloud-Unternehmen sagt. “Wir können architektonisch nicht auf Ihre Daten schauen, und hier ist der Bericht des Auditors, der es beweist” ist das, was wir anstreben.
Die Architektur ist absichtlich einfach. Passkey-primäre Authentifizierung über Apples eigene Frameworks. Standard-Krypto-Primitive (HKDF-SHA256, AES-KW RFC 3394). Lokale Dienste auf 127.0.0.1. Lokale Ollama-Inferenz. Es gibt sehr wenig neuartige Kryptografie, die man falsch machen kann, weil der primäre Sicherheitsmechanismus darin besteht, von vornherein keine Netzwerkverbindung zu haben.
Die vollständige technische Spezifikation – WebAuthn/PRF-Authentifizierung, HKDF-Schlüsselableitung, AES-KW-Wrapping, Aufbau der Wiederherstellungsphrase, Speicherhandhabung und Transport – lebt auf der Docs-Seite: Security technical specification. Der komplette plattformübergreifende Kryptografie-Vertrag, einschließlich jeder Konstante und jedes Testvektors, wird zur unabhängigen Prüfung verfügbar sein.
Transparenz heißt, genau zuzugeben, wo jedes Teil heute steht. Die Verschlüsselungstabelle oben zeigt den Status pro Komponente; das vollständige zeilenweise Verzeichnis – jedes Subsystem, sein Zustand und der konkret benannte Blocker für alles, was noch nicht live ist – wird auf der Docs-Seite gepflegt: Current build status.
If you think you have found a security vulnerability in any part of Ostler – the Mac Hub installer, the iOS app, the passkey helper, the Sparkle update pipeline, or any related infrastructure – please report it to [email protected]. Ein Mensch liest jeden Bericht und antwortet innerhalb von 72 Stunden.
Was wir im Gegenzug versprechen:
Was wir im Gegenzug bitten: Greifen Sie nicht auf die Daten anderer Nutzer zu, stören Sie unsere Dienste nicht und fordern Sie keine Zahlung als Bedingung für die Offenlegung. Wir betreiben zum Launch keine bezahlte Bug-Bounty – wenn sich das ändert, wird diese Seite es sagen.
Für verschlüsselte Meldungen ist unser öffentlicher PGP-Schlüssel unter /security.asc veröffentlicht. Die vollständige Disclosure-Policy ist gemäß RFC 9116 auch maschinenlesbar unter /security.txt verfügbar.
Die Sicherheitsgeschichte ist die Datenschutzgeschichte. Jeder Wettbewerber sendet Ihre Daten in die Cloud und verspricht, sie zu schützen. Wir behalten Ihre Daten auf Ihrer Hardware und beweisen, dass sie sie nicht verlassen können. Das ist kein Feature. Es ist die Architektur.
Konkretes · Kein Drumherumreden