Datenflüsse und Vertrauensgrenzen

Diese Seite trennt den aktuell belegten Android-plus-Cloud-Datenfluss vom breiteren Produktzielbild. Für den ersten Lieferstand ist nur der explizit markierte MVP-Pfad als aktuelle Runtime-Wahrheit zu lesen.

Achtung

Nicht als aktueller Android-v1-Runtime-Pfad belegt sind unter anderem:

• allgemeine Signalquellen wie Audio, Nachrichteninhalte, Browserdaten, Accessibility- oder Netzwerkanalyse
• Cloud-Enrichment über Hash-Lookups oder anonymisierte Feature-Vektoren
• lokale AES-256-Event- oder Log-Verschlüsselung
• aktive Blockierpfade gegen OS-, Call- oder Remote-Control-Aktionen
• gehostete Multi-Plattform- oder Multi-Tenant-Produktumgebungen

Aktuell verifizierter MVP-Datenfluss

Der heute belegte Datenfluss im Workspace sieht so aus:

Was dieser Pfad heute konkret umfasst

• Die Android-App hält base_url, api_token und tenant_id lokal in der App-Konfiguration.
• Für POST /devices erzeugt die App einen JSON-Body mit device_id, tenant_id, platform, status und public_key_b64 und signiert genau diesen Body mit einem lokalen RSA-Schlüssel aus dem Android Keystore.
• Für POST /events signiert dieselbe App ein tenant-gebundenes Demo-Event und sendet es an das lokale Backend.
• Dasselbe lokale Backend stellt tenant-scoped Reads für GET /status, GET /alerts, GET /incidents, GET /incidents/{id}, GET /jobs, GET /jobs/{id}, GET /traces/{id} und GET /traces/{id}/steps bereit.
• Die App kann Incidents ueber PATCH /incidents/{id} in ihrem Lifecycle weiterbewegen (Start review, Mark handled); dafuer braucht das Token incidents:write.
• Der verifizierte warn/high-Demo-Event kann im aktuellen Runtime-Pfad einen tenant-scoped Incident erzeugen.
• Operative Logs laufen heute über Android-logcat sowie Backend-stdout/stderr; ein eigener Telemetrie-Store oder eine eigene Metrics-Plane ist nicht belegt.

Aktuelle Vertrauensgrenzen

Grenze	Heutiger belegter Stand
Android-Gerät	App-Konfiguration, lokale device_id, Run-Snapshots und Android-Keystore-Schlüsselmaterial liegen lokal auf dem Gerät
Lokaler Transport	Der verifizierte Testpfad läuft über adb reverse zu http://127.0.0.1:8080; daraus folgt keine allgemeine Aussage über öffentliche Produktions-Topologien
Lokales Backend	superheld-cloud erzwingt im Secure-Mux tenant-gebundene Tokens und Scope-Prüfungen
Externe Systeme	Verifiziert sind heute vor allem REST-Reads und Webhooks auf dem lokalen Runtime-Pfad; darüber hinausgehende Produktintegrationen bleiben Zielarchitektur

Aktuell belegte Datentypen

Datentyp	Verlässt das Gerät im verifizierten MVP?	Aktueller Stand
App-Konfiguration (base_url, tenant_id)	Nein	lokal in der Android-App
Device-Registrierungsdaten	Ja	signierter JSON-Body an POST /devices
Demo-Event	Ja	signierter JSON-Body an POST /events
Alert-, Incident-, Job- und Trace-Reads	Ja	tenant-scoped Backend-Antworten an die App
Run-Korrelation (run_id, app_version, device_id, tenant_id)	Ja	als X-Superheld-*-Header auf verifizierten Telemetrie-Slices
App-Start-Logs	Nein	lokal in logcat unter SuperheldTelemetry
Backend-Logs	Nein	lokal im go run ./cmd/server-Prozess auf stdout/stderr

Zielarchitektur außerhalb des belegten MVP

Einige ältere Dokumente beschreiben breitere Datenflüsse. Diese sind nur als Zielarchitektur zu lesen, solange sie nicht ausdrücklich als verifizierter Runtime-Pfad markiert sind. Dazu gehören insbesondere:

• Signal Collection aus Audio-, Nachrichten-, Datei-, Browser- oder Accessibility-Quellen
• Cloud-Enrichment über SHA-256-Hashes oder anonymisierte Feature-Vektoren
• lokale Bedrohungsmodelle mit aktivem Blockieren statt des heute belegten Demo-Event-Pfads
• lokale AES-256-Event-Speicherung
• ein gehosteter Cloud-Service mit fest zugesagter Region, Retention und Betriebs-SLA

Frühere Produktclaims, die aktuell nicht als Ist-Stand gelten

Die folgenden Aussagen wären für den aktuellen Workspace zu stark und sollen nur noch als Zielarchitektur gelesen werden:

• “Es verlassen ausschließlich Hashes und Feature-Vektoren das Gerät”
• “Alle Events werden lokal AES-256-verschlüsselt gespeichert”
• “Audio- oder Nachrichteninhalte werden im ausgelieferten Android-v1-Pfad analysiert”
• “Policy-Entscheidungen blockieren heute aktiv OS-Aktionen auf Android”

Für die belegten Runtime-Endpunkte und Feldnamen sind API-Übersicht, OpenAPI und die Fact-Sheets maßgeblich.