Resolving security concerns on mjswan Cloud when uploading simulations with custom MDP via typescript source

[ttktjmt]

Context

Today mjswan Cloud is declarative-only: it accepts simulations whose MDP terms are composition graphs (pure data the engine interprets) and rejects any build that ships custom TypeScript (ts_src) — the publish step hard-fails on uses_custom_js: true. See ADR 0003 and ADR 0004 §10.

The custom-TS escape hatch (ObservationBinding(ts_src=...), etc.) stays a permanent, trusted-only capability for local / mjswan view / mjlab / the in-repo app, which load and register author modules directly. To reach Cloud today, an author must PR the needed primitive/slot to the engine.

This discussion is the future question: if we wanted to let authors upload simulations that carry custom-TS MDP code and have Cloud render them safely, how would we resolve the security concerns?

Threat model (why declarative-only today)

Custom ts_src runs client-side, in a viewer's browser, in the engine's JS realm — no server ever executes author code. So the relevant threat is XSS-class (author code running with the platform's origin authority: reading/writing another origin's DOM/cookies/tokens, executing where it shouldn't) — not server-side RCE/SSRF.

The CodePen analogy therefore applies — CodePen safely runs arbitrary user HTML/CSS/JS — but only by paying a permanent isolation cost: a separate sandbox origin, iframe sandbox, strict CSP, and constant XSS vigilance. Declarative data avoids foreign code by construction, so Cloud pays none of that.

Options on the table

1. Declarative-only (status quo). No foreign code; validation is set-membership on the engine's primitive registry. Trade: authors PR a primitive to reach Cloud; genuinely novel per-author logic can't be published until it lands.
2. No-import object-capability WASM (ADR 0004 §10, option A — recorded, not built). Compile the author term to a no-import WASM module instantiated with an empty import object: capability-free by construction — a module that needs an effect simply fails to instantiate. Upgrades Cloud from "declarative-only" to "effect-free arbitrary code."
3. WASM-hosted interpreter + capability object (QuickJS / Pyodide-in-WASM). Run author code inside a WASM-jailed interpreter, injecting only a narrow capability object (the physics slots). Structurally can't reach the host realm if the host bridge is closed and a CPU/time watchdog is added. (QuickJS-in-WASM was considered and rejected in ADR 0004 — worth revisiting the reasoning.)
4. CodePen-style native sandbox. Native execution + iframe sandbox + separate cookie-isolated origin + strict CSP + resource limits. Maximally compatible, but a perpetual XSS/CSRF-hardening commitment.
5. Review gate (manual + LLM). Hold custom-TS uploads pending cross-review before publishing. Doesn't scale; weak guarantee against subtle escapes; at best a transition mechanism.

Concrete concerns any non-declarative path must resolve

• XSS — origin isolation (separate sandbox domain), iframe sandbox, strict CSP (script-src / frame-src) so author code can't touch the platform origin's DOM/cookies/tokens.
• CSRF — any endpoint that runs or persists user code must use CSRF tokens and/or SameSite cookies, never ambient credentials.
• Resource exhaustion — even perfect origin isolation doesn't stop author code spinning CPU / exhausting memory / hanging the viewer's tab. Needs watchdogs / worker termination / instruction budgets. (Declarative + closed primitives bounds this for free.)

Question

Which path (if any) is worth building, and when? Is the declarative surface plus the "PR a primitive" on-ramp expressive enough that the restriction is rarely felt (the current bet) — or does the RL-research frontier produce enough genuinely-novel per-author logic to justify the perpetual cost of a sandbox, or the engineering of an ocap-WASM compile path?

Background: this question was surfaced while making the Gentle Humanoid demo's MDP terms fully declarative (#79). The declarative surface was widened with new fundamental primitives so more observations compose without author code, but the motion command remains the kind of effectful, stateful logic that motivates this question.

[ttktjmt]

cc: @unmoyai

[ttktjmt]

[Follow-up] A direction that goes beyond declarative-only

Building on the five options (+ ADRs 0003/0004), digging into the strategy led to a conclusion that is not "keep declarative-only and just raise the expressiveness ceiling," but rather recomposing the "data vs. trusted-only TS" dichotomy itself. Recording it here.

0. Premises we're now fixing

• Authors are untrusted (fully public self-serve). So against client-side, XSS-class threats we require by-construction safety (avoid monitoring-based isolation, i.e. a perpetual maintenance tax).
• The real pain is not "declarative is too weak." It is that effectful / stateful / interactive categories — Command / Event / Action — don't fit the data-ification mold, plus the DX friction of learning a primitive registry, composing it, and going through a PR.

1. The key reframe: break the false dichotomy

The ADRs frame the world as "effect-free data (safe)" vs. "effectful foreign code (dangerous)." That's a false dichotomy. The danger is neither being code nor having effects — it is being able to name an arbitrary effect (fetch / document / cookie / import). The object-capability principle: a computation cannot cause an effect it holds no reference to.

→ A third region: run effectful "code" over a closed sim-domain capability, in a realm with zero ambient authority. Authors get a full language, yet cannot structurally name origin authority. XSS / token exfiltration becomes impossible by construction, not by monitoring. Expressiveness far exceeds declarative; safety is the same "by construction."

2. Execution architecture: a separate MDP Worker, async

• We will not set COOP/COEP (to keep embedding behavior stable) → no SharedArrayBuffer → no Atomics.wait.
• Therefore untrusted author code is isolated in a dedicated MDP Worker, with asynchronous postMessage as the only channel. This also structurally sidesteps the lockdown-collision risk below (MuJoCo/ONNX/three do not co-reside in that worker).
• The async latency is not a "the control loop stalls" problem; it is contained to zero-order hold (keep using the last value until a new one arrives), lagging a few frames.

3. Substrate: spike both SES and QuickJS, decide empirically

• SES (Hardened JS): best as an idea (plain TS, same realm, best DX), but the risk that lockdown() collides with existing code is real. In some articles I checked, lockdown() collided with the host's Proxy-based internals and SES was abandoned in favor of QuickJS (Figma took the same route). This is a concrete precedent for our risk 1 (lockdown × MuJoCo / onnxruntime / three).
• QuickJS-in-WASM: never rewrites the host realm, so it's orthogonal to existing code by construction. Synchronous API and infinite-loop handling (terminate/interrupt) are easy. Per-step overhead is the open question.
• With the separate-worker premise the SES collision risk should drop, but that isn't a given → stand up both SES and QuickJS inside a lightweight MDP Worker and decide by measurement.

4. Per-category routing (handling the asymmetry)

Separate the categories where zero-order hold is benign from the one where it isn't:

Category	Meaning of async lag	Execution
Event (discrete, fires on reset/DR)	not even per-step	async ocap Worker
Command (user-input driven)	reflection just lags a few frames	async ocap Worker
Termination (bool end-of-episode)	termination just lags a few frames	async ocap Worker (when stateful)
Observation (policy input = in-control-loop signal)	policy acts on stale state = a control-quality problem	keep on the synchronous path
Action	—	stays mjlab's closed class set for now

A clean alignment: "the categories that genuinely need code (Command/Event)" and "the categories where async lag is benign" nearly coincide, while "the one category where async lag hurts (Observation)" is a pure function best served by the synchronous path. This structurally removes the control-loop-latency problem and keeps the MDP Worker lightweight (no need to put policy inference inside it).

5. Authoring: don't make people write a DSL — transpile mjlab Python

To kill the DX friction (registry learning) at the authoring layer, rather than making authors write a DSL, the main path transpiles the mjlab Python (raw value-extraction functions) directly to TS/JS. Building on the existing Python→IR tracer (src/mjswan/dsl/), split coverage three ways:

1. traceable → IR (synchronous, by-construction safe, already exists)
2. transpilable but not IR-expressible → ocap TS (static branches/loops, torch-specific ops, etc. run in the sandbox — the new region)
3. neither → manual TS port + automated output-consistency check (the true long tail)

The consistency check (verify numerical agreement between the Python reference and the TS output at build time) is mandatory on the auto-transpiled path too (torch→JS numeric-semantics drift fails silently otherwise).

6. Closing the trust boundary

• Capability danger (XSS/token): enforced at runtime purely by the engine-side realm isolation + endowment. No need to trust the author's build.
• Resource budget (metering / import restriction): the author uploads source, and Cloud compiles it deterministically with a sanctioned toolchain (compilation is not execution, so it's safe server-side). The author cannot skip metering.

7. The async contract (to be specified explicitly)

• Zero-order hold: keep the last value until a new one arrives.
• Reset barrier: Event(reset) is aligned with the physics reset at a logical-step boundary.
• Startup defaults: define each category's initial value for the first frame (never hang).
• Graceful degradation on worker death: on budget-kill / OOM, continue with the last value or a default — never hang.
• Determinism: drive MDP updates off a logical control-step counter, not wallclock → guarantees "everyone sees the same behavior" (async affects only when, never what).

8. Mapping to the five options

This direction takes options 2/3 (no-import WASM / WASM-hosted interpreter, i.e. the ocap family) and lands them in a concrete form: "separate async worker + SES/QuickJS + Python-transpile authoring." Option 1 (declarative-only) is retained as the synchronous Observation path; options 4 (CodePen-style iframe/CSP) and 5 (review gate) are dropped from the main line due to their perpetual maintenance tax.

9. Phasing and the next step

• MVP: open the ocap hatch for Obs/Termination/Command/Event (Action stays closed). Keep the existing declarative IR as the synchronous fast path.
• Phase 2: unified lowering (one authoring surface, auto-selected substrate, removing the "PR a primitive" wall).
• Later: shrink the tail with statechart-as-data for Command.

Next step (planned spike): a transpiler coverage study over mjlab observation terms

• Collect several dozen obs raw value-extraction functions from real projects.
• Classify them by the three-way split × per-family (locomotion / motion-tracking / muscle-myo / height-scan / history) × a semantic-risk flag.
• Measure the increment over the existing tracer's coverage as the baseline.
• Surface the non-transpilable patterns (torch-specific ops, dynamic branching, etc.).

The result reveals, in one shot: how far the IR must expand (the size of the option-B investment), the degree of ocap dependence, and the priority of the SES/QuickJS spike.

[ttktjmt]

[Follow-up 2] Running user MDP terms as data: ONNX graph capture, per-category

A concrete refinement of the "third region" idea. The headline: we already load onnxruntime-web for policy inference, and a custom MDP term is just a subgraph of the network. So instead of shipping author code (transpiled TS, or a sandboxed interpreter), we can ship author terms as captured computation graphs — pure data — and run them on the runtime that's already there.

The spine: capture, don't port

An mjlab observation term is func(env) -> tensor: it reads named physics quantities and does tensor math. Rather than transpile that Python to TS or run it in a sandbox, trace it with a stub env (leaf tensors registered as named input slots) and torch.export → ONNX, then ship the .onnx as data. The term becomes "one more small model."

Why this dominates the transpiler / interpreter routes:

• Maximal mjlab compatibility — authors write real torch; capture is automatic. No DSL to learn, no TS port. It's a natural evolution of the existing symbolic-env tracer (src/mjswan/dsl/) — same harness, ONNX output instead of a bespoke JSON DAG.
• Safe by construction — an ONNX graph is pure dataflow data; it cannot name ambient authority. No sandbox, no lockdown(), no COOP/COEP. Publish-time validation stays set-membership (opset ⊆ supported set), same spirit as the existing IR.
• Zero new runtime — no QuickJS, SES, or WASM toolchain. It rides on onnxruntime-web.
• Synchronous and fusable — satisfies the "observations stay on the synchronous path" requirement, and the obs graph can be fused into the policy graph: from the engine's view it's just a slightly larger policy taking raw slots in and actions out. Custom obs then needs essentially zero new engine machinery.
• Wider coverage than a hand-built DAG — ONNX expresses control flow (If/Loop/Scan) and state via explicit I/O (RNN-style), and torch's tracer handles broadcasting/reshape/reductions correctly.

Per-category strategy

Play-relevant categories only. Reward / Curriculum / Metrics-Recorder are train-only and out of scope.

Category	Nature	Primary strategy (safe = data)	ocap-code tail	Execution
Observation	pure state → vec	ONNX capture (fused into policy front-end)	truly data-dependent dynamics	sync
Action	pure transform of policy output → ctrl write	closed built-in set + params (existing); extension = ONNX fused into policy back-end + write to closed ctrl target	—	sync
Termination	pure state → bool	ONNX capture (bool output; timeouts read step_count as state I/O)	dynamic branching	sync
Event	side effect at reset	pure "value" graph (incl. RNG) + declarative mutation descriptor (existing); write targets from a closed registry	engine capability (e.g. terrain patches) → built-in, not per-author	sync / discrete
Command	stateful / interactive	tiered, mostly data (see below)	genuinely bespoke state machines	tail only, async

Notable specifics grounded in the current examples:

• Motion-reference obs (Mimic). MimicObservations.ts loads an .npz clip and indexes a reference frame by time. Since ADR 0004 §4 has the app own the bytes, the "async load" effect disappears: the term receives the clip as an input tensor and does Gather(clip, step_count) + tensor math — expressible in ONNX. Even this former ts_src term becomes capturable.
• Action symmetry. Action processing is ctrl = scale·raw + offset (+clip; Muscle adds a sigmoid). If obs is a front-end subgraph of the policy, a custom action is a back-end subgraph — captured to ONNX, appended, result written to the closed ctrl target. A safe extension hatch without opening arbitrary code (Muscle's sigmoid is already this shape).
• Command tiers. LiftingCommand.ts is the archetype: a resample timer, a target sampled from ranges (RNG), model-address reads, an object-qpos write, and a debug-marker render. Decompose rather than treat as one opaque blob:
  1. UI-driven (slider/button/checkbox) → existing UiCommand declarative data.
  2. Resampled goal (LiftingCommand-style) → data: {trigger: timer(range)|reset|manual, sample: uniform(range) graph, output slots, optional UI override}. Timer + RNG + range is a bounded pattern; the debug marker becomes a declarative display hint the engine renders (no three.js in author hands).
  3. Motion-tracking → engine capability (named class; app feeds bytes).
  4. Genuinely bespoke state machine → the one place that needs the ocap-code tail.

The big implication: the sandbox surface shrinks hard

With ONNX capture for Obs/Action/Termination and the existing declarative descriptors for Event, Observation, Action, Termination, and Event all reduce to data and run synchronously inside the engine — no worker. The untrusted-code execution surface collapses to Command tier 4 (bespoke stateful), plus the rare obs/termination that won't lower to a graph.

This changes the MVP scope: we do not need to build the asynchronous ocap worker, zero-order-hold, and reset-barrier machinery up front. Those categories are data and run synchronously; the async ocap worker can be deferred until a genuinely bespoke Command term actually appears. "The best code is the code you don't write yet."

Open verification

• Confirm onnxruntime-web opset support per op — especially control flow (If/Loop/Scan), Gather, and RandomUniform.
• RNG determinism ties into the earlier determinism contract: seed random ops off the logical control-step counter, so async (where it exists) affects only when, never what.

Revised next step

Reframe the planned spike from "transpiler coverage" to graph-capture coverage: over several dozen real mjlab obs terms (stratified by family — locomotion / motion-tracking / muscle-myo / height-scan / history), measure how many cleanly torch.export → ONNX via a stub env, which need control-flow ops, which need state I/O, and which are irreducibly dynamic (→ ocap tail). The result sizes the ONNX opset we must support and the true remaining sandbox tail in one pass.