SOWA Privacy für Entwickler

Aus dem Quellcode installieren

SOWA Privacy wird über den Chrome Web Store als Binary ausgeliefert, der Quellcode ist jedoch zur Prüfung und persönlichen Nutzung unter der Source-Available-Lizenz in LICENSE zugänglich. So erstellen und laden Sie es lokal:

git clone https://github.com/Sowa-Privacy/sowa-privacy-chrome-extension.git
cd sowa-privacy-chrome-extension
npm install
npm run build

Öffnen Sie dann chrome://extensions/, aktivieren Sie den Entwicklermodus und klicken Sie auf Entpackt laden und wählen Sie den Ordner dist/.

Drei große Drittanbieter-Bundles

Einmalig mit esbuild vor Vite erstellt, sodass der Produktions-Build vollständig in sich geschlossen ist:

• web-llm.bundle.js – ~5,4 MB – lokale LLM-Inferenz (optional, Opt-in).
• transformers.bundle.js + onnx-wasm/* – ~32 MB – NER-Pipeline-Laufzeit (optional, Opt-in).
• file-parsers.bundle.js + pdf.worker.min.mjs + xlsx-worker.bundle.js – ~2 MB – PDF-, DOCX- und XLSX-Parsing für den Datei-Upload-Interceptor.

Was drin steckt

manifest.json                 Chrome MV3 Manifest (einzige Quelle der Versionsnummer)
contentScript.js              MV3 Content-Script-Einstiegspunkt
service_worker.js             MV3 Service Worker (zustandslos)
offscreen.js                  Offscreen-Dokument für NER-Inferenz

lib/
  constants.js                DEF_CONFIG, PRESET_PATTERNS, NER_MODELS,
                              WEBLLM_MODELS, INDUSTRY_BLACKLISTS
  pii-core.js                 detectPII, mergeDetectionHits, Blacklist + Regex-Pipeline
  ner-detector.js             NER-Pipeline + Diagnosezustand
  ui-utils.js                 shouldUseRegex / NER / LLM Hilfsfunktionen, Theme, Debounce
  ui_i18n.js                  t() + RESOURCES (4 Sprachen) + applyI18n
  cs/
    owl-guardian.js           Owl-Widget Shadow DOM, Dauerscan, Badge-Zähler
    upload-interceptor.js     Datei-Drag/Drop- und Datei-Input-Interceptor
    host-matcher.js           contentIntegration.entries Pattern-Matching

tests/unit/                   688 Unit-Tests – müssen grün bleiben
scripts/                      esbuild-Bundle + ZIP-Paketierung

Datenschutzgarantien

Dies sind die im Code durchgesetzten Regeln, keine bloßen Marketing-Versprechen:

• Kein Telemetrie, keine Analyse, keine eigenen Server-Aufrufe – mit einer eng begrenzten Ausnahme: die eigene Berechtigungsprüfung des Nutzers (ein einzelner authentifizierter POST an /api/entitlements/me, der ausschließlich die Plan-Flags des Nutzers zurückgibt). Für eine Stunde zwischengespeichert. Keine PII, keine Prompts.
• NER standardmäßig AUS, nur Opt-in – das NER-Modell ist ein 65 MB großer Drittanbieter-Download (HuggingFace). Es beginnt erst zu laden, wenn der Nutzer den Schalter in den Einstellungen explizit aktiviert.
• Lokales LLM standardmäßig AUS, nur Opt-in – gleiche Regel. WebLLM-Modelle sind groß; der Download liegt in der Entscheidung des Nutzers.
• Owl ist auf die Website beschränkt – das Content-Script registriert sich auf <all_urls> für Lifecycle-Hooks, aber Erkennung, Modell-Vorwärmen und das Owl-Widget laufen nur auf den sieben Hosts in contentIntegration.entries (ChatGPT, OpenAI, Claude, Gemini, Copilot, Grok, x.ai).
• CSP verbietet dynamische Code-Ausführung – 'wasm-unsafe-eval' für ONNX ist erlaubt; 'unsafe-eval' nicht. Kein Function-from-string, keine eval-gesteuerten Plugins.
• Nur Promises für chrome.*-APIs – kein Callback-Muster, das die Fehlerbehandlung verschleiert.
• Zustandsloser Service Worker – MV3 beendet ihn aggressiv; Persistenz liegt in chrome.storage, nicht in Modul-Globals.

Tests

Tests sind das primäre Korrektheitskriterium. Stand v1.2.5.x: 688 von 689 erfolgreich in 17 Test-Suiten. Neuer Code muss dies grün halten.

npm run test:unit:nocov   # schneller Loop während der Entwicklung (~3s)
npm run test:unit          # CI-Gate mit Coverage
npm run typecheck          # tsc --noEmit
npm run lint               # eslint

Bugfixes folgen dem TDD-Ansatz: erst den fehlschlagenden Test schreiben, dann den Fehler beheben – der Test bleibt als Regressionsschutz. Ein echtes ausgeliefertes Beispiel: tests/unit/lib/ner-detector.test.js – der Test „detect-counter does NOT reset on subsequent init successes“ wurde vor dem zugehörigen Fix geschrieben und fing einen fehlerhaften ersten Implementierungsversuch ab.

Beitragen

Beiträge zum offiziellen Repository sind unter den Lizenzbedingungen willkommen. Öffnen Sie ein Issue oder reichen Sie einen Pull Request gemäß den Engineering-Standards in CONTRIBUTING.md ein:

• Branch von main. Eine logische Änderung pro PR.
• Commit-Nachrichtenkonvention: type(scope): description (vX.Y.Z.W).
• MIGRATION_LOG.md für nicht-triviale Änderungen aktualisieren (neue Module, Vertragsänderungen, architektonische Verschiebungen).
• Checkliste vor dem Einreichen für PRs, die Erkennung oder Netzwerk betreffen: kein neuer fetch() zu einem eigenen Server, kein neues Telemetrie, keine automatisch aktivierte schwergewichtige Komponente, alles Gespeicherte kommt ins Migration-Log, jede neue Berechtigung ist für den Chrome-Web-Store-Prüfer begründet.

Verantwortungsvolle Offenlegung

Bitte öffnen Sie bei Sicherheitslücken keine öffentlichen GitHub-Issues. Senden Sie einen detaillierten Bericht per E-Mail an security@sowaprivacy.ai:

• Klare Beschreibung der Schwachstelle.
• Schritte zur Reproduktion.
• Betroffene Version (das Feld version in manifest.json).
• Risikoabschätzung, falls vorhanden.
• Vorgeschlagener Fix, falls zutreffend.

Wir verpflichten uns, Ihren Bericht innerhalb von 72 Stunden zu bestätigen, innerhalb von 7 Tagen ein Status-Update zu liefern, Sie in den Release Notes zu nennen (sofern Sie keine Anonymität bevorzugen) und den Zeitpunkt der öffentlichen Offenlegung mit Ihnen abzustimmen.

Der veröffentlichte Scope, Beispiele für das, was wir als Schwachstelle betrachten, sowie ein Hall of Fame befinden sich in SECURITY.md im Stammverzeichnis des Repositories.