Sicherheit

Parla arbeitet mit deinem Mikrofon, deshalb ist es so gebaut, dass es schwer zu missbrauchen ist. Deine Stimme verlässt nie dein Gerät, die Erweiterung verlangt so wenig wie möglich, und jedes Stück Code, das wir ausliefern, wird festgeschrieben, gescannt und getestet, bevor es bei dir ankommt.

Während du Parla nutzt

• Deine Stimme wird auf deinem Gerät bereinigt, im Browser. Parla hat keinen Server, der Audio empfängt, und keine Konten oder Passwörter, die gestohlen werden könnten.
• Die Engine ist unser eigener Code, in Rust ohne Bibliotheken von Drittanbietern geschrieben, und läuft als WebAssembly in der Sandbox des Browsers. Die KI-Modelle sind Daten (Zahlen), keine Programme: Kein Code der Modellautoren läuft auf deinem Computer.
• Die Erweiterung verlangt nur, was das Bereinigen eines Mikrofons braucht: ihre Einstellungen zu speichern und auf den Seiten zu laufen, auf denen du dein Mikrofon nutzt. Ihre eigenen Seiten führen nur ihre eigenen Skripte aus (eine strenge Content Security Policy).
• Webseiten erreichen die Erweiterung nur über einen schmalen Kanal: Sie bekommen die Dateien der Engine und sonst nichts, und alles, was sie senden, wird geprüft und in der Größe begrenzt.
• Berichte sind aus, bis du sie einschaltest. Sie sind anonym, und jedes Feld ist in unserer Dokumentation aufgeführt.

Von unserem Code in deinen Browser

• Alles, was der Build verwendet, ist auf eine exakte Version festgeschrieben und wird über seinen Fingerabdruck geprüft: GitHub Actions per Commit, Container-Images per Digest, Downloads per SHA-256, npm- und Python-Pakete per Lockfile.
• Kein Release, das jünger als 3 Tage ist, wird übernommen. Die meisten bösartigen Paketversionen werden innerhalb weniger Tage entdeckt und entfernt, also lassen wir sie zuerst auffliegen. Automatische Updates warten eine Woche, und jedes wird gebaut und getestet, bevor es angenommen wird.
• Pakete dürfen nie Installationsskripte ausführen, und die Signaturen der npm-Registry werden bei jedem Build geprüft.
• Nur unsere automatisierte Pipeline baut Releases, aus dem Hauptzweig. Die Zugangsdaten für die Stores und npm liegen in einer geschützten Umgebung, die nur der Release-Schritt nutzen kann, und der Build behält das Zugriffstoken des Repositorys nicht.

Bei jeder Änderung geprüft

• Statische Analyse: CodeQL liest das TypeScript, die Rust-Engine und die Build-Workflows; zizmor prüft die Workflows.
• Ein dynamischer Scan der Website (OWASP ZAP) bei jeder Änderung und jede Woche.
• Eine Änderung, die ein Paket mit einer bekannten Schwachstelle hinzufügt, wird blockiert, und Dependabot-Warnungen überwachen jedes Lockfile.
• Secret-Scanning mit Push-Schutz: GitHub lehnt jeden Commit ab, der ein Passwort oder einen Schlüssel enthält.
• Streng typisierter Code (TypeScript und Python) und automatisierte Tests in Chrome und Firefox vor jedem Release.

Ein Problem gefunden?

Bitte sag es uns vertraulich: Schwachstelle auf GitHub melden. So kann es behoben werden, bevor es öffentlich wird.

Alles auf dieser Seite lässt sich überprüfen: Der Code, die Build-Pipeline und die Sicherheitsprüfungen sind Open Source. Wie Releases gebaut und geprüft werden