Languages and Runtimes | Attack the Glass

Whatever an adversary places into a Client Runtime, the language hosting that runtime determines what the placement can do. Eval, dynamic loading, runtime compilation, in-memory state modification, network interception, privileged API access: these are not adversary techniques. They are properties of the language and its runtime, available to whatever code happens to be executing. An adversary who acquires placement inherits whatever the language permits.

Language, platform, and provider vary independently of one another. The platform is the runtime that hosts the language; the providers are the supply chain that delivers content into that runtime. Knowing which language an application is written in does not tell you which platforms host it; knowing the platform does not tell you which providers it loads content from; and knowing the providers does not tell you which languages their code and content are written in.

JavaScript in the browser is the loudest case because the web is the largest installed base that assembles what the user sees on the device itself (client-side rendering, or CSR), but the same analysis applies to Swift on iOS, Kotlin on Android, Lua in user-generated content (UGC) runtimes, Python in notebook and productivity front-ends, and the long tail of languages that build screens on the device in vehicles, appliances, control systems, and augmented and virtual reality headsets.

Seventeen language-level capabilities, split into two groups, describe what a language permits. Eight code-introduction capabilities govern how adversarial code or content arrives in the runtime; nine runtime-manipulation capabilities govern what arriving code can do once it is there. Which of these seventeen capabilities a language supports determines its level of risk.

A language's contribution to the ATG attack surface depends on its presence in user-experience surfaces across the deployed Client Runtime landscape, not only on what its runtime permits. Capability and reach together produce a spectrum of risk.

Browser-specific primitives that constrain a subset of the seventeen capabilities do not transfer as code to other Client Runtimes. Architectural patterns can translate even where implementing code cannot. Three patterns translate: SSoT (a single source of truth) for runtime resources, content-swap detection, and in-memory anti-manipulation.

4.1: Why the Language Matters

Of the three dimensions, language is the one that determines what is technically possible inside the runtime. The platform constrains where the runtime ships and how it is updated. The provider constrains what content arrives and from whom. The language constrains what the runtime is allowed to do when content arrives and execution begins. Take a runtime that does not permit dynamic evaluation of code from a string: an adversary who places a string of code into that runtime cannot execute it. Take a runtime that does not permit modification of a peer's in-memory state: an adversary placed alongside a sensitive code path cannot reach into that path. The boundaries of the attack surface are language-level boundaries. Platforms and providers determine reach and delivery; the language determines what reach and delivery can produce.

The Manifest Illusion, Data as Code, and Code That Writes Code are language-level properties. The Manifest Illusion arises in a runtime to the extent that the language permits dynamic loading of code from sources determined at runtime. Data as Code exists to the extent that the language permits content (a string, an image, a configuration file, a manifest) to be coerced into executable behavior, whether through eval, embedded scripting, unsafe deserialization, or auto-fetched declarative content that interprets at load time. Code That Writes Code exists to the extent that the language permits running code to compile, evaluate, or otherwise produce further executable behavior at runtime. These are not abstract architectural patterns. They are conditions a language and its runtime either satisfy or do not satisfy, and a language that satisfies all three gives an adversary the full toolkit for ATG operations inside the runtime that hosts it.

That picture extends across every Client Runtime in scope, not the browser-hosted JavaScript runtime alone. Lua in a Roblox-style UGC runtime supports dynamic loading and runtime evaluation; an adversary who places a Lua module into that runtime inherits the same toolkit a JavaScript adversary inherits in a browser, calibrated to the Lua runtime's API surface. Hermes, the JavaScript engine inside React Native mobile applications, carries that same JavaScript model into those applications. The Python kernel inside a Jupyter notebook supports import-time and exec-time code introduction with full access to the host process. The renderer for USDZ, Apple's 3D scene format, interprets scene files whose declarative content carries behavior with it; on iOS that renderer is the AR Quick Look viewer. Each is a Client Runtime; each has its own capability profile; each is exploitable through the language-level conditions its runtime satisfies.

4.2: What Languages Allow

A language's contribution to the ATG attack surface is the set of capabilities its runtime makes available to running code. Seventeen capabilities, eight code-introduction and nine runtime-manipulation, cover the language-level conditions ATG operations require. The two groups are interdependent. Code-introduction determines whether an adversary can arrive. Runtime-manipulation determines what arriving code can do.

Code-introduction capabilities. The eight answer a single question: how does adversarial code or content arrive in the runtime in a form the runtime will execute? Each is a distinct mechanism by which a Client Runtime expands its executing code base after the initial load. Languages and their runtimes vary in which subset of the eight they support, and the more they support the larger the surface through which an adversary can introduce executable behavior.

eval: dynamic evaluation of code from a string. The string can originate anywhere the language permits a string to come from, including a network response, a stored value, an attribute on a markup element, or a piece of user-generated content. JavaScript's eval and Function constructor are the examples in browsers and in JavaScript-engine-based mobile and desktop runtimes. Lua's loadstring plays the equivalent role in UGC runtimes such as Roblox. Python's exec and eval operate in Jupyter kernels, productivity tools, and any embedded Python interpreter. The capability is the most direct realization of Data as Code: any input the runtime evaluates becomes executable code.
dynamic load: runtime loading of code modules from sources determined at runtime. The destination is decided after the application starts rather than fixed at build time. ES module dynamic import() in browsers, Node.js require() paths constructed at runtime, Hermes module loading inside React Native, Java reflection-driven class loading inside JVM plugin hosts, native dynamic library loading inside desktop applications, and loaders for over-the-air (OTA) bundles inside mobile applications, meaning code updates pulled straight from a server after install without going back through the app store, all instantiate the capability. The capability is the realization of the Manifest Illusion: the runtime fetches and executes code whose source and integrity are decided at fetch time, not at build time.
runtime compile: compilation of source code on the fly into executable form. The runtime takes source text and produces in-process executable behavior without a separate build step. Browser JavaScript engines compile every script the runtime loads. Lua compiles loadstring inputs at call time. Python compiles imports and exec inputs at call time. WebAssembly runtimes that accept module bytes from arbitrary sources compile them on receipt. The capability is the upstream condition for Code That Writes Code: a runtime that can compile source at runtime can be made to produce further executable behavior from any string the running code generates or fetches.
embedded scripting: the host language permits scripted execution inside data or markup that the runtime treats as content. HTML's
unsafe deserialization: deserialization formats whose parsing logic can produce code execution. Python pickle, Java serialization, .NET BinaryFormatter, YAML loaders that instantiate arbitrary classes, and a long list of model-distribution formats in AI runtimes all fall into the category. The runtime takes a serialized blob and reconstructs in-process objects whose construction can invoke arbitrary code. The capability turns the routine ingestion of saved state, model weights, document content, and configuration data into a code-execution channel.
plugin marketplace: the language ecosystem includes a plugin or extension distribution channel that a runtime loads from. Browser extension stores, IDE plugin marketplaces, mobile app extension surfaces, smart-TV app stores, vehicle infotainment marketplaces, productivity-tool add-in galleries, and game-engine asset stores all expose the same structural pattern: third-party code distributed through a centralized channel and loaded into the runtime with the same permissions as the application's own code. One compromised publisher account therefore reaches every runtime that installed the plugin.
auto-fetched declarative content: declarative content that the runtime auto-fetches and interprets at load time, where interpretation produces runtime behavior. CSS that fetches fonts, images, and additional stylesheets; web manifests; configuration files that specify dependencies to resolve; AI prompt templates that pull other prompts; action manifests for models that are allowed to act on their own; localization bundles that contain templated content. The boundary between data and code dissolves at the interpretation step. The capability is a quieter realization of Data as Code than eval: the runtime is not asked to execute a string, but the declarative content it interprets ends up directing executable behavior.
hot-reload or OTA update: runtime code update without application restart. React Native CodePush, Expo OTA, Capacitor live updates, auto-update of the display bundles inside desktop application shells such as Electron, mobile app on-demand bundle delivery, vehicle infotainment over-the-air feature updates, and game-engine live patches all fit. The runtime accepts a new version of executable code and swaps it in while the application is running. The capability is why placement at an OTA pipeline reaches every device on the channel without re-deployment, and the reason mobile and embedded Client Runtimes are not less exposed than browsers despite shipping precompiled binaries. Runtime-manipulation capabilities. The nine answer a different question: once code is executing inside the runtime, what is it allowed to do? Each names a class of effect that running code can produce in the surrounding runtime, in other code's state, in the rendering pipeline, in the network layer, in storage, in privileged APIs, in background execution contexts, and in user input handling. A language's runtime-manipulation profile is what determines the D5 effects an adversary can produce once placement and code introduction have succeeded.
in-memory state modification: modifying objects, prototypes, variables, or function bindings of other code in the running process. DOM manipulation in browsers, prototype pollution in JavaScript engines, monkey patching in Python and Ruby, native object swizzling in Objective-C and Swift, JVM bytecode manipulation in plugin hosts, and arbitrary state mutation in shared-memory runtimes are all instances. The capability is a primary lever for information manipulation: an adversary that can rewrite a DOM node, an answer returned by a model, or a rendered string can produce a deception that the user reads as legitimate output of the host application.
data injection between code paths: one code path inserting data into another's flow. The injection target may be a function call, a message channel, an event handler, an inter-component message bus, an inter-frame communication channel, an inter-process pipe, or an embedded data-flow graph. Cross-component injection in single-page applications, postMessage abuse between iframes, intent injection in Android, URL-scheme handler abuse on iOS, message-port hijacking in WebViews, and inter-app sharing abuse on embedded platforms all operate through the capability. The capability enables information manipulation at the seam between trusted code paths, where each path treats the other's output as input it does not need to re-validate.
media manipulation: modifying images, video, or audio in memory or before render. Canvas-level pixel manipulation, WebGL shader manipulation, decoded video frame editing, audio buffer rewriting, pre-display image processing in AR/VR rendering pipelines, and on-device synthesis of substitute media are instances. The capability sits at the operational center of on-device tailored deception.
rendering cycle control: forcing or delaying repaint, forcing reload, manipulating the render loop, modifying the scene graph, intercepting layout passes, or rewriting the rendered output between layout and presentation. Browser requestAnimationFrame hijacking, scene-graph mutation in game engines and AR/VR runtimes, render-pass manipulation in mobile UI frameworks, and HUD-overlay manipulation in vehicle infotainment all operate through the capability. The capability allows information manipulation to land at the moment of presentation rather than at the moment of computation.
network interception: intercepting and modifying network requests and responses originating from the runtime. fetch and XHR hijacking through prototype patching, Service Worker interception in browsers, WebSocket manipulation, native HTTP-client interception in mobile and desktop runtimes, request-rewriting middleware in productivity-tool plugin hosts, and on-device proxy hooks in embedded environments are all instances. The capability turns the runtime into the man-in-the-middle for its own outbound traffic.
persistent storage manipulation: reading and writing persistent storage that survives session restart. Cookies, localStorage, sessionStorage, IndexedDB, cache storage, native key-value stores, embedded SQLite databases, file-system access surfaces, and platform-specific secure storage all fall into the category. An adversary with persistent storage access can implant state that re-establishes presence on the next session, exfiltrate accumulated data on a scheduled cadence, or rewrite values that the application trusts on subsequent loads.
privileged runtime API access: using sensitive runtime APIs that grant capability beyond rendering. Browser-side examples include the clipboard API, geolocation, the camera and microphone, notifications, the file system access API, push notifications, and payment APIs. Mobile and embedded Client Runtimes add device-specific surfaces: Bluetooth, NFC, SMS, contacts, calendar, telephony, biometric APIs, sensor and actuator APIs in IoT and vehicle Client Runtimes, and hardware-access APIs in control-system Client Runtimes. The capability transforms a foothold inside the runtime into capability that reaches into the physical world.
background execution context manipulation: spawning or hijacking execution contexts that operate without user awareness. Web Workers, Service Workers, browser background timers, requestIdleCallback, native background tasks on iOS and Android, embedded scheduler tasks in vehicle and IoT runtimes, and headless contexts in productivity-tool plugin hosts are all instances. The capability decouples adversarial activity from user-facing rendering, which is operationally significant because most user-side detection signals are tied to user-facing rendering.
user input event control: intercepting, suppressing, or fabricating user input events. Click, key, touch, gesture, sensor-input, form submission, voice, gaze, and controller input events all fit. The capability allows running code to perform actions on the user's behalf without the user originating them, and to suppress evidence that the actions occurred. In spatial Client Runtimes (AR/VR, automotive HUD), gaze and gesture event control extends the capability into modalities where user awareness of the manipulation is lower than in keyboard-and-mouse interaction. A language may have any subset of the seventeen, and where it sits across the full set is what shapes its risk. Together the capabilities cover the language-level conditions for the Manifest Illusion, Data as Code, and Code That Writes Code, and for the full D5 effects spectrum an injected resource can produce. Several runtime-manipulation capabilities (in-memory state modification, media manipulation, rendering-cycle control, data injection between code paths) are direct levers for information manipulation, the dominant ATG attack mode.

Several of the runtime-manipulation capabilities have established defenses inside the browser. The defenses are browser-specific.

4.3: User Experience Attack Surface by Language

A language scores against a second axis: whether it actually reaches user-experience surfaces in deployed Client Runtimes. A language with all seventeen capabilities but rare presence in user-facing rendering produces a small attack surface in practice. A language with fewer capabilities but global presence in user-experience surfaces produces a large one. A language's reach into user-experience surfaces is its User Experience Attack Surface.

User-experience presence runs along a four-step ramp: global, common, sometimes, rare. The ramp is scored across all Client Runtime platforms in scope, not the browser alone.

Global: the language is dominant in user-facing rendering across many Client Runtime platforms. JavaScript, HTML, and CSS rate global. They appear across browsers, mobile WebViews and hybrid frameworks (React Native, Capacitor, Cordova), desktop application shells (Electron, Tauri), smart-TV runtimes, vehicle infotainment systems, smart-home interfaces, productivity-tool plugin hosts, and the long tail of platforms that embed a JavaScript engine for user-experience rendering. A global rating means a single language's capability profile reaches user-experience surfaces across the deployed landscape.
Common: the language is dominant in user-facing rendering inside a particular Client Runtime platform category and absent or rare outside it. Swift and Objective-C rate common (global within iOS-class Client Runtimes, rare elsewhere). Kotlin and Java rate common (global within Android-class Client Runtimes, rare elsewhere). Lua rates common (global within several UGC runtimes and embedded scripting contexts, rare in mainstream consumer rendering). C# rates common (game engines and the .NET application shell, less elsewhere). The common rating identifies a language whose user-experience reach is bounded by a platform category and is nonetheless very large within that category.
Sometimes: the language appears in user-facing rendering in specific contexts but not across a platform category. Python rates sometimes: present in Jupyter notebooks, several productivity-tool front-ends, scientific-computing dashboards, and an increasing set of AI-tooling user interfaces, but not in mainstream consumer mobile, browser, or smart-TV rendering. USDZ rates sometimes: present in iOS AR Quick Look and adjacent AR contexts, not across general application surfaces. The sometimes rating identifies a language whose presence in user-experience surfaces is real and growing but bounded by use-case rather than by platform category.
Rare: the language appears in user-facing rendering only in narrowly defined contexts. C and C++ rate rare in user-facing rendering despite their high capability profiles, because most user-experience rendering on top of C and C++ runtimes is delegated to languages further up the stack. Rust rates rare for the same reason in current deployment, with caveats for the emerging practice of compiling rendering code to WebAssembly. Assembly and bytecode languages typically rate rare. The rare rating does not mean the language is unimportant in the Client Runtime landscape; it means the language's presence in user-experience surfaces is narrow. JavaScript sits at the high end of both: most of the seventeen capabilities and a global user-experience presence, which is the reason JavaScript is the dominant case. C and C++ sit at high capability but rare user-experience presence, and they contribute to the attack surface mostly indirectly, through the runtimes they host rather than through user-facing rendering they perform directly. Python sits at high capability but sometimes user-experience presence; the contribution is significant in the contexts where Python is the rendering language and limited elsewhere. The two-axis read is what matters, not a single-number ranking.

Risk is a spectrum across the two-axis read, not a binary of safe versus unsafe languages. True immunity in the CSR sense is rare, and where it exists it almost always means the runtime falls outside the ATG scope entirely: a precompiled-only Client Runtime that does not load runtime resources, a server-rendered static HTML page with no client-side scripting, a native compiled binary with no remote runtime loading, a terminal application with no Glass surface. Those runtimes are genuinely immune. A runtime that loads nothing at render sits outside the scope of the ATG vulnerability. What makes ATG consequential is not that immunity is unreachable but that reaching it means giving up runtime assembly, which is the capability that made CSR worth adopting. Within the boundary, low-risk profiles exist (few capabilities present, low user-experience presence, common in restricted embedded UIs, some kiosk runtimes, and certain appliance dashboards), but they are positions at the low end of the same spectrum, not separate categories of safety.

4.4: Notable Language Profiles

Five language profiles show how the two-axis read produces operational analysis. Per-language details live in the Reference Matrix Languages sheet and the printable matrix sheets in the back matter.

Table 4.4: Notable language profiles. Capability presence per language, with User Experience Attack Surface prevalence.
Language	eval	dyn load	emb script	OTA	mem mod	net intercept	priv API	UX
JavaScript	yes	yes	yes	yes	yes	yes	yes	Global
Swift / Obj-C	limited	yes	limited	yes	yes	yes	yes	Common (iOS)
Kotlin / Java	limited	yes	limited	yes	yes	yes	yes	Common (Android)
Lua	yes	yes	yes	limited	yes	limited	limited	Common (UGC)
Python	yes	yes	limited	limited	yes	yes	yes	Sometimes
USDZ	no	no	yes	yes	yes	no	limited	Sometimes (AR)
C / C++	no	yes	no	no	yes	yes	yes	Rare

Table 4.4: Notable language profiles. Capability presence per language, with User Experience Attack Surface prevalence.

Y: capability present in normal runtime use. L: present in limited or restricted form. N: capability not present in normal use. Capability columns: eval, dynamic load, embedded scripting, hot-reload or OTA update, in-memory state modification, network interception, privileged runtime API access. UX: User Experience Attack Surface presence per the four-step ramp.

JavaScript sits at the high end of both axes. The language carries every code-introduction capability that matters in a Client Runtime (eval, dynamic load, runtime compile, embedded scripting, plugin marketplace, auto-fetched declarative content, and hot-reload or OTA update) and every runtime-manipulation capability (DOM and prototype manipulation, data injection, media manipulation, render-cycle control, network interception, persistent storage manipulation, privileged API access, background execution contexts, and user input event control). User-experience presence is global: browsers, hybrid mobile frameworks, desktop application shells, smart-TV runtimes, vehicle infotainment, smart-home interfaces, and productivity-tool plugin hosts all rely on a JavaScript engine for user-facing rendering. The combination is the reason JavaScript is the dominant ATG language profile and the reason most existing defensive primitives (Content Security Policy, Subresource Integrity, Trusted Types, the Permissions API) target it. The defensive coverage in the browser is real; outside the browser, the same JavaScript runtime engines (JavaScriptCore, Hermes, V8 in Electron, embedded V8 in vehicle and smart-TV systems) carry the capability set without the matching defensive primitives.

Swift and Objective-C sit at moderate code-introduction and high runtime-manipulation, with common user-experience presence inside iOS-class Client Runtimes. eval-style dynamic evaluation is restricted; dynamic load operates through framework-loading and plugin-host APIs; embedded scripting comes through WebView-hosted content rather than native script tags; hot-reload arrives through OTA bundle delivery channels. Once code executes, the runtime-manipulation surface is wide: native object swizzling, in-memory state modification, full network-stack interception, and access to the device's privileged APIs (camera, microphone, location, contacts, biometrics, sensor and actuator surfaces). The profile is illustrative of the native-mobile case: code-introduction is gated harder than in JavaScript, but runtime manipulation, privileged-API reach, and user-input-event control are at least as wide. Where the language exposes a JavaScript runtime through embedded WebViews or JavaScriptCore, the JavaScript profile applies inside that runtime.

Lua sits at high code-introduction inside the runtimes that host it and moderate runtime-manipulation, with common user-experience presence in UGC and embedded scripting contexts. eval (loadstring), runtime compile, dynamic load, and embedded scripting are all present. Hot-reload is platform-dependent. Runtime-manipulation is bounded by the host runtime's API surface: in a UGC runtime such as Roblox, Lua scripts can manipulate game-world state, intercept user input events, and modify the rendered scene, while network interception and privileged-API access are gated by the host platform's sandbox model. The profile is illustrative of the embedded-scripting case: code-introduction is wide because Lua is purpose-built as an embeddable scripting layer, while runtime manipulation depends on what the host runtime exposes. The UGC variant of the profile is operationally significant because the user-content channel is also the code-distribution channel; arbitrary Lua arrives through user-uploaded experiences and is executed at runtime by every user who joins.

Python sits at high code-introduction and high runtime-manipulation, with sometimes user-experience presence. The language carries eval, exec, dynamic import, runtime compilation, plugin marketplaces (PyPI plus IDE and notebook extension surfaces), and unsafe deserialization (pickle). Runtime-manipulation includes monkey patching, full network access through the host process, persistent storage access through file-system surfaces, and privileged-API access mediated by whatever the host environment exposes. User-experience presence is bounded: Jupyter notebooks, productivity-tool front-ends, scientific-computing dashboards, and an increasing set of AI-tooling user interfaces are the primary Client Runtimes where Python performs user-facing rendering. The profile is illustrative of the high-capability low-prevalence case: where Python is the rendering language, the contribution to the ATG attack surface is large; where it is not, the contribution arrives through the files the language produces (notebook outputs, generated reports, files produced by AI pipelines) that are then rendered in another language's runtime.

USDZ sits at limited code-introduction, moderate runtime-manipulation, and sometimes user-experience presence in iOS AR Quick Look and adjacent AR contexts. USDZ carries no scripts. It carries a declarative behaviors schema of triggers and actions that the AR runtime interprets while it renders, so eval and dynamic load have no equivalent here. The asset still directs what the scene does: Data as Code without a script engine. Hot-reload arrives through asset replacement in the AR session. Runtime-manipulation is at the rendering layer: scene-graph mutation, media manipulation in the AR rendering pipeline, and rendering-cycle control. Network interception and privileged-API access are largely gated by the host AR runtime. The profile is illustrative of the spatial-runtime case: the capability set is narrower than JavaScript's but operates at the point of presentation, where the user has little basis for doubting what is shown; manipulation at the AR rendering layer reaches a user-experience surface where confidence in the rendered output is elevated by the immersive context.

JavaScript shows what a global presence on top of a wide capability set produces. Swift shows what gated code-introduction with full native-mobile runtime reach looks like. Lua shows what a purpose-built embedded scripting layer brings into the host runtime's capability frame. Python shows the high-capability, sometimes-presence case where the contribution is large in the contexts the language renders and indirect everywhere else. USDZ shows the spatial-runtime case where the surface is narrower and the presentation context elevates the consequence.

4.5: Defense Across Languages

Each browser-specific defense is built for the browser as a runtime. Content Security Policy works in a browser. It does not work in a Lua interpreter, a Python kernel, a USDZ scene-graph renderer, a Hermes runtime inside a React Native application, an embedded JavaScript engine inside a vehicle infotainment system, a Java or Kotlin runtime on Android, a Swift runtime on iOS, a C or C++ runtime in embedded firmware, a JVM language in a desktop plugin host, or a language runtime embedded in a smart-home hub, an IoT dashboard, or a productivity-tool extension host. Subresource Integrity works for browser script loading and for nothing else. The Permissions API gates sensitive APIs in browsers and has no equivalent elsewhere. Trusted Types constrains DOM injection sinks in browsers and applies only to the DOM. The browser-specific defense ecosystem is genuinely valuable inside the browser; outside the browser, none of the four can be lifted as code into another runtime.

Each of those defenses targets a capability that exists in every Client Runtime, not only in browsers. Network interception is a runtime-manipulation capability of every runtime that issues network requests. Privileged API access is a property of every runtime that exposes APIs to running code, and the privileged-API surface is wider in mobile, embedded, vehicle, and IoT Client Runtimes than in browsers. Static script integrity is something every runtime that loads scripts can pin, and most do not. DOM injection sinks are a browser-specific case of in-memory state modification, and other runtimes have analogous sinks in their own state-modification surfaces. The capability is the same in every runtime, but the defense is browser-only, and the gap widens as the capability set grows.

Three architectural patterns are reusable across Client Runtimes.

SSoT for runtime resources: a service that maintains the reference for what a runtime should be loading (scripts, data, media, CSS, fonts, configuration, model weights, prompts, plugin manifests, and any other resource the runtime fetches and applies) and detects deviations from the reference at load or execution time. The SSoT pattern is implementable in any Client Runtime: in a browser as a runtime-resource manifest service that observes fetch and dynamic import; in a React Native application as a bundle-and-asset manifest service that observes the OTA update channel and the Hermes module loader; in a Roblox-style UGC runtime as an experience-asset manifest service that observes the script-loader and the asset cache; in a Jupyter kernel as a notebook-asset manifest service that observes import, exec, and pickle deserialization; in a vehicle infotainment system as a manifest service that observes the OTA pipeline and the runtime's resource cache. The implementing code is different in each runtime. The architecture is the same.
Content-swap detection: the detection problem of identifying content arriving at the runtime that differs from the authorized content is shared across runtimes. Methods of detecting the swap (cryptographic comparison against an SSoT reference, behavioral profiling of expected content shape, anomaly detection at the load boundary, runtime monitoring of content as it is interpreted) are reusable as methods even when the code that implements each method is runtime-specific. The cross-runtime work is the method library; the per-runtime work is the integration into each runtime's resource-loading and resource-applying paths.
In-memory anti-manipulation: detecting modifications to runtime state, to monitored objects, and to rendering pipelines is a pattern that applies across every runtime that exposes the runtime-manipulation capabilities. The steps carry across: declare which regions of state are monitored, instrument whatever loads or modifies those regions, and detect departures from what was declared. The implementing code differs by runtime. The design is recognizable across them. All three patterns are the language-level expression of Malice Without Malware. Defenses purpose-built for Client Runtimes have to come from the runtime itself: detecting manipulation, detecting deception, and detecting attempts to steer behavior. At the language level, the three patterns are what those defenses look like.