Knoten, Kabel und Ausführung getrennt halten

Ein Knoten beschreibt Werkzeug, Eingabe und sichtbare Ausgabe; ein Kabel nur die beabsichtigte Datenübergabe. Eine gezeichnete Verbindung ist weder Ausführungserlaubnis noch Beweis für kompatible Datentypen.

Sichere Orchestrierung übergibt Text nur auf Nutzerwunsch. Dateiauswahl, Passwortfelder, Codeausführung, Netzwerkanfragen und Downloads bleiben ausdrücklich manuell.

  • Stabile Werkzeugkennungen speichern.
  • Eingaben vor der Übergabe prüfen.
  • Fehler je Knoten sichtbar halten.
  • Folgenreiche Aktionen nicht automatisieren.

IndexedDB und AES-GCM richtig einordnen

Projektdokumente können mit frischem Initialisierungsvektor pro Datensatz und dem Projektbezeichner als authentifizierten Zusatzdaten verschlüsselt werden. Ein nicht exportierbarer CryptoKey in derselben IndexedDB hält den Ablauf serverlos.

Diese Verschlüsselung schützt nicht vor einem kompromittierten Gerät, einer bösartigen Erweiterung oder feindlichem Code desselben Ursprungs. Werden Website-Daten und Schlüssel gelöscht, ist der Chiffretext nicht wiederherstellbar. Browserkontingent und datenschutzgerechte Backups bleiben Nutzeraufgaben.

  • Schema und Größe vor und nach Entschlüsselung prüfen.
  • Für jeden Datensatz einen neuen 96-Bit-IV erzeugen.
  • Kontingentfehler verständlich anzeigen.
  • Löschfunktionen anbieten.

Rezept-URLs sind kein geheimer Kanal

Knoten und Kanten lassen sich als begrenztes JSON definieren, gzip-komprimieren und Base64url-codieren. Importiert werden dürfen nur bekannte Versionen, Werkzeug-Slugs und gültige Referenzen innerhalb fester Größenlimits.

URLs können in Verlauf, Zwischenablage, Nachrichten und Screenshots erscheinen. Ausgaben müssen immer und Eingaben standardmäßig entfernt werden. Ein noindex-Importpfad ist Suchmaschinenhygiene, aber keine Zugriffskontrolle.

  • Keine Passwörter oder Dateien serialisieren.
  • Eingaben nur durch gesondertes Opt-in aufnehmen.
  • Unbekannte Schemaversionen ablehnen.

WebRTC benötigt Signalisierung und einen Identitätsabgleich

RTCDataChannel schützt die Übertragung mit DTLS, aber Angebot, Antwort und ICE-Kandidaten müssen ausgetauscht werden. Ohne Signalisierungsdienst geschieht dies mit einmaligen Codes, die nach zehn Minuten verfallen und Netzwerkinformationen enthalten können.

DTLS beweist nicht die reale Identität des Absenders. Beide Personen vergleichen deshalb einen aus Raum, Peer-IDs und DTLS-Fingerprints abgeleiteten Sicherheitscode über einen zweiten Kanal. Abweichungen können eine aktive Zwischenstelle zeigen; Übereinstimmung ist dennoch keine Identitätsprüfung. Die Live-Freigabe beginnt pausiert und wird gesondert aktiviert.

Ohne STUN und TURN können NAT, Unternehmens-Firewall oder Browserregeln die Verbindung verhindern. Begrenzte Einladungen, Transfers, Chunks, Dokumentgrößen und DataChannel-Puffer reduzieren Ressourcenmissbrauch.

  • iceServers leer lassen.
  • Codes kurzlebig und einmalig halten.
  • Sicherheitscode vor der Freigabe vergleichen.
  • Keine Identitätsgarantie behaupten.

Leistung und Tests

Der Editor wird nur auf der Workstation-Route dynamisch geladen; Kompression gehört in einen Web Worker. Vollständige Werkzeugfilter, Startabläufe, automatische Anordnung, Rückgängig/Wiederholen und eine mobile Einspaltenansicht verhindern, dass ein Canvas zur Barriere wird.

Der Agent zeigt Konfidenz und Auswahlgründe vor einer Änderung. Tests decken Rezept-Rundlauf, Schemata, AES-GCM-Manipulation, Kontingentwache, gefälschte Pfade, abgelaufene Signalcodes, symmetrische Sicherheitscodes sowie noindex und Canonical ab. Peer-Erreichbarkeit bleibt netzabhängig.