sandboxing of plugins and config

[samuelstroschein]

Orginially from #129 but moved to a discussion.

The config architecture of inlang is similar to Figma's plugin system. Figma allows developers to write plugins in JavaScript that are executed in the browser, similar to inlang's desire to execute config code in the browser. This article on Figma's blog goes into great length on different sandboxing approaches and trade-offs. Figma initially chose the Realms shim developed by Agoric. The Agoric Realms approach was eventually compromised and Figma switched to a WebAssembly-based JavaScript runtime.

The design requirement for inlang are as follows:

• Eliminate malicious attacks that have impact beyond inlang components.

  A DOS (Denial of Service) attack by, for example, blocking the main thread via while (true) would be okay since it affects only a component itself and poses no harm outside of an app becoming unresponsive. Being able to access auth tokens stored in cookies via the global window variable in browsers could be devastating though.

• Async. Otherwise, the main thread (UI) is blocked each time some config code is executed.

  This point is unrelated to the DOS argument. The DOS argument "crashed" the app once, and it's clear that the config is malicious. Blocking the main thread with each execution entails that the UI will lag. A bad UX, not a malicious attack. Running config related code in a webworker could mitigate the need for async. However, plugins would not have access to the DOM. Whether access to the DOM is required or not is to be determined.

• Support the import of external scripts/packages.

  The flexibility of defining readResources() and writeResources() is handy but the ability to import third party code that deals with reading and writing resources reduces the adoption friction.

• Expose variables/APIs.

  Functions defined in the config like readResources() require the expose of a filesystem API. Dynamic business logic like onSave() requires the expose of variables too. The simplest (consuming) API is likely to pass those variables when executing functions. For example, readResources() would become readResourced(fs: FileSystem).

Comparison

Method	Secure	ESM consumption	Async	Third party code	Bundle size
dynamic import	❌	✅	✅	?	0kb
SES	✅	❌	?	❌	?kb
Shadow Realms	?	✅	❌	?	0kb in the future
Quick JS (runtime)	✅	❌	✅	✅	~1MB

ESM consumption refers importing and accessing code as if the code would not be sandboxed:

const module = await import('sandboxed-code')

const result = module.exampleFunction()

Third party code refers to the ability to import external code within the config:

// inlang.config.js
import { x } from "https://some.module/x.js"

Overview

Dynamic import is not suited due to zero security. SES seems suitable but third party code is not supported.

[samuelstroschein]

Not required anymore after the #1142 refactoring.

• config is now JSON
• plugins won't be able to import JS anymore