Twitch Extensions currently appear to block modern WebAssembly-based client runtimes, including Rive, because the Extension CSP script-src does not include either 'wasm-unsafe-eval' or 'unsafe-eval'.

Rive’s web runtime is a JavaScript/WASM runtime. Even when the developer self-hosts the rive.wasm file inside the Extension bundle, the browser still has to compile and instantiate WebAssembly at runtime. Under current CSP behavior, that compile/instantiate step is blocked unless script-src includes 'wasm-unsafe-eval' or the broader and less desirable 'unsafe-eval'.

This is not primarily a third-party CDN issue. Rive supports self-hosting its WASM file through RuntimeLoader.setWasmUrl(...), so developers can avoid loading from unpkg or another external host. The remaining blocker is the CSP permission to execute WebAssembly.

The requested change is NOT to allow general JavaScript eval(). The safer path would be to add an opt-in, review-gated capability for WebAssembly support that adds only: script-src ... 'wasm-unsafe-eval'

'wasm-unsafe-eval' is narrower than 'unsafe-eval': it permits WebAssembly compilation/instantiation without enabling arbitrary string-to-JavaScript execution through eval(), new Function(), string-based setTimeout(), etc.

A security-preserving implementation could work like this:

• Add an Extension capability such as “Allow WebAssembly runtime”.
• Require the capability to be approved during Extension review.
• Require all .wasm assets to be included in the submitted Extension bundle.
• Disallow loading .wasm from arbitrary external domains, even if the Extension has external connect-src domains for APIs.
• Keep the existing restrictions on inline scripts, external scripts, iframes, and general eval().
• Keep requiring human-readable JavaScript for review, with WASM files submitted as separate reviewed assets.
• Optionally require developers to declare each WASM asset filename, size, hash, and purpose in the Extension submission.
• Optionally reject dynamic runtime construction patterns such as compiling WebAssembly bytes fetched from non-extension API domains.

I believe this would preserve the current Extension security model while enabling a narrow class of reviewed, deterministic client runtimes.

The concrete use case is Rive animations. Rive is useful for Twitch Extensions because it enables lightweight, interactive, state-machine-driven animations for overlays, panels, alerts, mini-games, and viewer feedback. These are exactly the kinds of experiences Extensions should support, but up until today, we must fall back to other approaches such as spritesheets, videos, GIFs, Lottie, or custom canvas animation code.