Attack the Glass (ATG)

The Platform Landscape

A language describes what running code is permitted to do. The platform describes what surrounds the running code: the channel that delivered it, the isolation around the runtime, the device APIs the runtime exposes, and the population of devices receiving the same delivery. A JavaScript engine carries the same language-level capability profile in a browser, in a desktop application shell such as Electron, in a smart television, and in a vehicle infotainment dashboard. The four ATG profiles those four hosts produce are not the same.

Platforms, languages, and providers vary independently of one another: a single platform category usually hosts several language runtimes, the same language usually appears on several platform categories, and knowing the platform or the languages does not tell you which providers deliver content into its runtimes.

ATG operates against Client Runtimes that assemble what the user sees on the device itself (client-side rendering, or CSR); Client Runtimes that run only code compiled before shipping are out of scope. Most modern platform deployments are CSR-capable, but the variation is real and runs inside almost every category. Mainstream consumer browsers, mainstream mobile phones, mainstream smart televisions, mainstream vehicle infotainment systems, mainstream IoT management dashboards, and mainstream productivity-tool extension hosts are all CSR-capable. Specialized deployments inside the same categories, including hardened embedded firmware, safety-critical avionics, and certain real-time control loops, may be precompiled-only and out of ATG scope.

Eight conditions describe what a platform contributes to ATG exposure. Each shapes how adversarial code arrives, what surrounds the running code once it executes, and what reach the runtime exposes beyond itself. Where a platform sits across the eight is what shapes its risk.

Conditions are the first axis. The second is device scale, treated as a blast-radius indicator: how many devices a successful platform-level compromise reaches, in order-of-magnitude terms rather than as a unique-device count. Billions of devices for the dominant browser-and-mobile categories. Hundreds of millions for desktop and game runtimes. Tens of millions and below for specialized surfaces.

Ten platform categories host Client Runtimes at meaningful scale, from browser and mobile at the top through desktop, productivity, and the non-browser surface categories.

Five patterns recur across the categories.

Implementing code does not translate from one platform to another. A verifier built for React Native CodePush, which delivers over-the-air (OTA) updates (code pulled straight from a server after install, without going back through the app store), does not run on a vehicle infotainment update channel; a browser-shell Permissions API does not exist inside the renderer of a desktop application shell such as Electron, or inside a smart-TV application; nothing equivalent to CSP exists for a renderer of USDZ files, Apple's 3D scene format, or for a Lua runtime hosting user-generated content (UGC). Architectural patterns can translate even where implementing code cannot. SSoT (a single source of truth) for runtime resources, content-swap detection, and in-memory anti-manipulation apply at the platform level, with platform-specific implementation challenges added to each, and the defensive-maturity falloff outside the browser is the gap the patterns are designed to close.

5.1: Why the Platform Matters

Of the three dimensions, the platform is the one that determines where the runtime lives and what surrounds it. The language constrains what running code is allowed to do. The provider constrains what content arrives and from whom. The platform constrains the channel that delivered the content, the isolation around the running code, the device APIs the runtime can reach, and the population of devices a single delivery reaches.

Once an adversary has acquired placement on a Client Runtime, the platform's conditions determine what the placement reaches. An OTA bundle channel determines whether the placement reaches a single device or every device on the channel. Runtime isolation determines whether the placement is contained inside its declared scope or escapes into surrounding application and operating-system state. The device APIs determine whether the placement reaches the camera, the biometrics subsystem, the vehicle telemetry interface, or the industrial actuator surface. None of these are language properties; none are provider properties. They belong to the platform.

Every platform category contains deployments on both sides of the CSR-capable / precompiled-only line, and many individual devices contain both. The mainstream CSR-capable cases include consumer browsers, mobile phones running hybrid frameworks and OTA bundles, smart televisions, vehicle infotainment systems, IoT management dashboards, and productivity-tool extension hosts. On the precompiled-only side: hardened embedded firmware in some appliances, safety-critical avionics, and certain real-time control loops in industrial process equipment. The per-device split is itself a feature of several categories. A vehicle's infotainment runtime is CSR-capable; the safety-critical engine and brake electronic control units (ECUs) on the same vehicle are precompiled-only; ATG operates on the infotainment side. The same pattern recurs in IoT, where the management dashboard is CSR-capable and the underlying real-time control firmware is precompiled-only, and in control systems, where the human-machine interface is CSR-capable and the programmable logic controllers and remote terminal units behind it are precompiled-only. ATG scope follows the runtime, not the device. A runtime sits outside that scope only where three conditions are all enforced: every runtime resource is pinned to its content rather than to its address or its certificate, no code is generated or evaluated at runtime, and no runtime-fetched data drives what is rendered or what executes. Meeting the first two and failing the third is the condition the Two-Stage Attack is built for, because the first-stage code passes every check made before delivery, and what gets swapped rides in the data. Across the browser, mobile, desktop-shell, appliance, productivity and user-generated-content categories, the CSR-capable case is the mainstream deployment. In IoT, vehicle and control-system categories it is the interface layer rather than the whole estate, and those interfaces are the ones most likely to pin their sources and least able to stop fetching the live data they exist to render.

5.2: What Makes a Platform an ATG Surface

A platform's contribution to the ATG attack surface is the set of conditions it imposes on the runtime it hosts. Eight conditions cover the ground ATG operations require beyond the language layer.

  • Update and distribution channel: how new code reaches the platform: app store review channels (iOS App Store, Google Play, Microsoft Store, smart-TV app stores, vehicle infotainment marketplaces); OTA bundle delivery (CodePush, Capgo, Expo OTA, vehicle infotainment OTA, smart-TV firmware OTA); web auto-update (consumer browsers, SaaS clients); manual install (desktop installers, sideloaded APKs); and developer-mode sideload. Each channel is a Placement and Access (P&A) vector with its own review depth, signing requirements, publisher identity verification, and population of accepting devices. The same compromised package distributed through an app store with active human review reaches a different population, on a different timeline, than the same package distributed through OTA on a fleet-update channel.
  • Runtime isolation: whether the platform sandboxes running code or runs it with broad system privilege. Browsers sandbox the renderer process; iOS and Android sandbox each app to its own address space; container runtimes isolate workloads. Desktop applications run with the user's privilege level and can reach the file system, network, and many platform APIs. IoT firmware commonly runs with full system privilege, and certain embedded human-machine interfaces have no isolation between rendering code and control-system access. In Electron, the split between the rendering process and the surrounding shell separates rendering from Node.js access to the machine, but that boundary holds only where the application is configured to keep the renderer away from Node.js, and it is frequently misconfigured. Isolation determines whether placement at the rendering layer can reach state belonging to the host application or the operating system around it.
  • Plugin and extension hosting: whether the platform admits third-party plugins, extensions, add-ins, or asset packs as a first-class feature, and through which marketplace structure. Browser extension stores (Chrome Web Store, Firefox AMO, Edge Add-ons), IDE plugin marketplaces (JetBrains Plugin Repository, VSIX (the Visual Studio extension format), Eclipse Marketplace), Office Add-ins, smart-TV app stores, vehicle infotainment app stores, productivity-tool add-in galleries, and game-engine asset stores (Roblox catalog, Unity Asset Store) all instantiate the pattern. Review depth, publisher identity verification, and runtime constraints applied to plugin code vary widely across them. Plugin and extension hosting is a P&A vector by design: third-party code is admitted into the runtime as a first-class feature and runs with the host application's permissions.
  • Multi-language runtime hosting: whether the platform hosts more than one language runtime in the same address space. Electron hosts JavaScript via V8 alongside Node.js native modules. Jupyter hosts Python, R, Julia, and additional languages through its kernel architecture. React Native hosts JavaScript in the Hermes engine alongside native code running through the host platform's Swift, Objective-C, Kotlin, or Java runtimes. Vehicle infotainment shells frequently host an embedded JavaScript engine alongside the native vehicle-API runtimes. Each hosted runtime brings its full language-level capability profile into the platform; the platform's ATG profile combines the capabilities of every hosted runtime and is not held down to those of the most restricted one.
  • Device API exposure: which privileged APIs the platform exposes to running code. Browser-side: clipboard, geolocation, camera, microphone, notifications, file system access, push notifications, payment, and the broader Permissions API surface. Mobile-side: Bluetooth, NFC, SMS, contacts, biometrics, sensor APIs, telephony, and on certain platforms vehicle and industrial telemetry. Vehicle infotainment exposes vehicle telemetry, climate control, and increasingly cabin and seat actuators. IoT and control-system platforms expose the actuator surfaces that physically affect equipment in the world. The capability that converts a runtime foothold into physical-world reach lives here.
  • Persistent storage model: what state survives across sessions and updates. Cookies, localStorage, sessionStorage, IndexedDB, and Cache Storage on the browser side. App sandbox file storage, key-value preference stores, secure enclaves, and embedded SQLite databases on mobile. File system access on desktop. Embedded device-side stores on IoT and vehicle platforms. Persistent storage is the channel through which a placement re-establishes itself after a session restart, accumulates exfiltrated data on a scheduled cadence, and rewrites values that the application trusts on the next load.
  • Update authority: whether updates require user consent, are prompted but accepted by default, or are pushed silently. Mainstream consumer browsers auto-update in many configurations. App store updates often run silently in the background. OTA bundle delivery on mobile, vehicle, smart-TV, and IoT platforms is silent by default. The OTA model is the silent-update extreme: the runtime accepts a new bundle from the upstream service without any user-side decision. On a silent-update path nobody asks the user, so the user has no point at which to refuse.
  • Network model: the platform's default network behavior and the controls that exist over outbound calls. Browsers enforce same-origin policy and CORS, and admit Content Security Policy and Permissions Policy when the application declares them. iOS enforces App Transport Security; Android exposes the network security config. Desktop applications, IoT firmware, and many embedded platforms have no analogous default constraints and admit outbound calls to arbitrary destinations. The network model determines what controls (if any) constrain a placement's ability to call home, exfiltrate data, fetch additional code, or contact a command-and-control endpoint. Together the eight conditions cover where placement is admitted, what surrounds it once executing, what state survives between sessions, and what beyond-runtime reach the runtime exposes.

Several of the eight have meaningful defaults inside the browser; most other platform categories carry weaker defaults across the same conditions, and some carry no analog at all.

5.3: Device Scale and Platform Reach

A platform scores against a second axis: how many devices a single platform-level compromise reaches. A platform with severe conditions across a small device population produces a bounded total impact. A platform with milder conditions across billions of devices produces a large one.

Device scale runs from billions of devices at the top through hundreds of millions for the major application platforms and into the tens of millions and below for specialized surfaces. Browsers and mobile operating systems sit at the top, with Chromium-based engines, WebKit/Safari, iOS, Android, and the embedded browser engines that ship inside other categories together accounting for billions of devices in active use. Desktop application shells (Electron, Tauri, the JVM plugin hosts), the major game and interactive runtimes (Roblox, and the aggregate user populations across Unity and Unreal titles), the major productivity-tool extension hosts, and smart televisions in mainstream brands sit at hundreds of millions. Vehicle infotainment, IoT management dashboards in narrower deployments, control-system human-machine interfaces, AR/VR runtimes, narrower productivity-tool surfaces such as Jupyter notebooks, and digital-signage networks sit in the tens of millions and below.

A single Android phone counts against the Android operating system, against the Chromium-based browser engine, and against any React Native or hybrid app installed on it that hosts its own JavaScript runtime. Device scale is a blast-radius indicator, not a unique-device count, and overlap across categories is expected. The comparative reading is the point: an OTA bundle delivery channel that touches a billion devices and an OTA bundle delivery channel that touches ten million devices represent different aggregate risk pictures even when the per-device exposure is identical. The Reference Matrix Platforms sheet captures the per-category reading in its Devices (Global) column.

Total impact is the conditions multiplied by the device-scale. Two platforms with identical profiles produce different total-impact pictures when their device populations differ by an order of magnitude, and two platforms with identical device populations produce different total-impact pictures when their profiles differ.

5.4: The Ten Platform Categories

Ten categories cover the platforms that host Client Runtimes in deployment today. Per-framework details live in the Reference Matrix Platforms sheet and the printable matrix sheets in the back matter.

CategoryIsoPlugMLangAPIUANetScale
BrowserB
MobileB
Desktop App ShellHM
AppliancesHM
IoTTM
VehicleTM
Control SystemTM
AR / VR / SpatialTM
Game / UGCHM
Productivity / DataHM
Table 5.4: The ten platform categories. Condition presence per category, with device scale band.

Y: condition present in normal platform configuration. L: present in limited or restricted form. N: not present in normal configuration. Iso: runtime isolation; Plug: plugin and extension hosting; MLang: multi-language runtime hosting; API: device API exposure; UA: silent update authority by default; Net: network controls comparable to same-origin, CORS, CSP, and ATS. Scale: device scale band (B = billions; HM = hundreds of millions; TM = tens of millions and below).

Browser. The dominant Client Runtime host: the Chromium-based engines (Chrome, Edge, Brave, Opera, embedded WebView, embedded Electron renderer), the Firefox/Gecko family, and the WebKit/Safari family. The browser's profile combines strong runtime isolation (the renderer sandbox), first-class plugin hosting (extension stores), heavy auto-update with silent default, and the deepest existing defensive ecosystem of any platform category (CSP, SRI, the Permissions API, Trusted Types, COOP/COEP, the Origin model). Device scale sits at billions, and the user-visible per-device exposure runs from web pages through extension surfaces to the embedded-engine instances that ship inside other categories. The operationally significant ATG risk patterns are CDN-delivered third-party script compromise, browser-extension publisher takeover, and browser auto-update channel compromise reaching every browser instance on the channel. Mainstream browsers are uniformly CSR-capable; specialized stripped-down embedded browsers in some kiosk and appliance configurations approach precompiled-only behavior but rarely fully achieve it.

Mobile (Native, Hybrid, OTA Bundle Delivery). The iOS and Android families, plus the cross-platform frameworks (React Native, Flutter) and the hybrid WebView frameworks (Cordova/Capacitor) and the OTA-update vectors that ship with them (CodePush, Capgo, Appflow, Expo OTA). Mobile platforms combine strong app-level sandboxing with rich device-API exposure (camera, microphone, biometrics, location, sensors, payment, contacts, telephony) and silent OTA bundle delivery on the hybrid side. The OTA bundle channel is significant: it is silent-update at population scale, and it admits new JavaScript bundles into running applications without app-store review. Device scale sits at billions across Android and iOS. The operationally significant ATG risk patterns are OTA bundle compromise, WebView-hosted content compromise, and hybrid bundle replacement during an application session. Mainstream mobile deployments are CSR-capable through hybrid frameworks, WebViews, and OTA channels; pure-native applications without WebViews and without OTA approach precompiled-only behavior, but the combination is rare on modern phones.

Desktop App Shells (and Plugin Hosts). Electron, Tauri, JavaFX WebView, Qt WebEngine, and SWT Browser as application-shell runtimes; IntelliJ Platform, Eclipse RCP, VSIX, Blender, GIMP, Anki, Maya, Houdini, and FreeCAD as plugin hosts; Office Add-ins as the productivity-shell case. Desktop application shells host the full browser engine inside a non-browser shell, with the shell exposing OS-level APIs (file system, network, process control) that browsers do not. The profile combines first-class multi-language hosting (JavaScript via embedded engine plus native code via the shell's bridges), broad device-API exposure (the host operating system), first-class plugin hosting, and weak defaults on the network model: Electron applications can call any host by default unless the application configures restrictions. Device scale sits at hundreds of millions, with Electron alone embedded in widely deployed IDEs, communication clients, password managers, and productivity software. The operationally significant ATG risk patterns are plugin-marketplace publisher compromise, Electron renderer-shell isolation failure where node integration is misconfigured, and supply-chain compromise of the embedded JavaScript engine or native modules. Universally CSR-capable through embedded browser engines and plugin runtimes.

Appliances (TV, Signage, Smart Home). Smart televisions (Tizen, webOS, Android TV, Roku, Fire OS), digital signage networks (BrightSign, Scala, NoviSign), and smart-home hubs (Google Home, Amazon Echo Show, the various SmartThings-class hubs). Many appliances run a full browser engine under the hood for their user-experience surface, often without the browser-class defensive ecosystem around it. Update authority is silent by default (firmware OTA at the network level, app-store auto-update at the application level), runtime isolation is uneven across vendors, and the device-API surface includes the appliance's hardware (camera, microphone, and lighting or HVAC controls in smart-home cases). Device scale sits at hundreds of millions for the major smart-TV families and lower for narrower categories such as digital signage. The operationally significant ATG risk patterns are connected-appliance silent update, app-store publisher compromise within the appliance ecosystem, and the inherited reach of the same Chromium-derived engine inside the appliance shell with weaker defenses around it. Older or low-end appliance firmware may be precompiled-only and out of scope; mainstream connected appliances are CSR-capable.

IoT (POS, Medical, Edge). Point-of-sale terminals, medical-device dashboards (patient-monitoring displays, infusion-pump operator interfaces, imaging-modality consoles), and edge computing nodes that expose management or operator interfaces. CSR-capable runtimes are commonly used for the management and configuration layer rather than for real-time control. Runtime isolation is often weak or absent (the management runtime executes with broad system privilege), update authority is silent OTA from the device vendor's management plane, and the device-API surface includes the actuator surfaces that physically affect equipment in the world. Device scale sits in the tens of millions and below across narrower deployments, but the per-device consequence runs into physical-world impact: payment data, medical-device behavior, edge-node control of downstream equipment. The operationally significant ATG risk patterns are management-dashboard compromise via the runtime layer, vendor OTA channel compromise reaching every device on the channel, and downstream actuator manipulation through a compromised management interface. Some real-time control firmware within IoT devices is precompiled-only and out of ATG scope; the management dashboards and operator interfaces are typically CSR-capable.

Vehicle (Automotive Infotainment). In-vehicle infotainment systems (the Tesla infotainment UI, Ford SYNC, GM Infotainment, Mercedes MBUX, BMW iDrive, Volvo Polestar, the various Android Automotive deployments) and the OTA update channels that maintain them. Infotainment runtimes are CSR-capable through embedded browser engines and OTA bundle delivery; infotainment is kept away from the vehicle's safety-critical control bus by a gateway device sitting between the two networks, not by anything the runtime itself enforces. Device APIs include vehicle telemetry, climate control, and increasingly cabin and seat actuators, with vendor-specific gateway connections to driving-relevant subsystems. Device scale sits in the tens of millions and below, with growth as connected-vehicle penetration increases. The operationally significant ATG risk patterns are infotainment OTA compromise, supply-chain compromise of the infotainment runtime stack, and gateway-traversal attacks that reach beyond infotainment into safety-critical subsystems. The infotainment Client Runtime is CSR-capable; the safety-critical engine, brake, and steering ECUs are typically precompiled-only and out of ATG scope. ATG operates on the infotainment side; the gateway between infotainment and safety-critical systems is a structural concern in its own right, but it is not where ATG operates.

Control System (OT, SCADA, DCS). Operational-technology and industrial-control-system human-machine interfaces, or HMIs (Wonderware/AVEVA, Siemens WinCC, Rockwell FactoryTalk, GE iFIX, and the other vendor platforms), and the engineering workstations that maintain them. HMI runtimes are CSR-capable through embedded browser engines, scripting layers, and dashboard frameworks; runtime isolation between the HMI and the control-system network is operationally segmented but rarely enforced at the runtime layer. The device-API surface includes the actuator commands the HMI sends to the underlying PLC and RTU layer. Device scale is small in absolute terms, but the per-device consequence is the largest of any platform category: cascading control of physical infrastructure. The operationally significant ATG risk patterns are HMI compromise via the rendering or scripting layer, engineering-workstation compromise reaching the HMI deployment pipeline, and command injection through the HMI to the underlying control layer. The HMI layer is generally CSR-capable; the underlying PLC and RTU control layer is often precompiled-only. ATG operates at the HMI; downstream consequences traverse the HMI-to-control gateway.

AR, VR, and Spatial. AR Quick Look (USDZ on iOS), VR runtime engines (Meta Horizon, SteamVR, OpenXR-based runtimes), and spatial-computing platforms (Apple Vision Pro, Meta Quest, the various enterprise AR platforms). Spatial runtimes are CSR-capable through asset auto-render (USDZ scenes loaded from a URL render with embedded behavior), runtime scene-graph manipulation, and asset-pack distribution. Device-API exposure includes cameras, depth sensors, eye and gesture tracking, and the spatial position of the user. The user-experience layer is distinctive: the immersive context elevates the user's confidence in rendered output, and gaze, gesture, and voice give the user fewer cues that something has been tampered with than a keyboard and mouse do. Device scale sits in the tens of millions and below, with growth on a longer time horizon than mobile or desktop. The operationally significant ATG risk patterns are USDZ AR Quick Look compromise (a tap on a link renders a malicious USDZ scene, and nothing asks the user to consent to executing it), VR or AR app-store publisher compromise, and asset-pack distribution channel compromise. Universally CSR-capable across mainstream deployments.

Game and Interactive Runtime (UGC). User-generated-content runtimes that load and execute scripts and assets supplied by other users: Roblox (Lua-based experience scripting), modded Minecraft servers, Unity AssetBundle delivery, Unreal Engine pak files, Garry's Mod and similar Source-based UGC, and the broader category of game engines that load and execute client-side content from a content server. UGC runtimes are CSR-capable by design: the runtime accepts user-supplied scripts and assets and executes them in the host application's address space. Runtime isolation between user-supplied scripts and the host engine varies across platforms, but supplied scripts run with the engine's API surface and reach. Update authority on the asset side is silent: a new asset version goes live the next time the runtime fetches it. Device scale sits at hundreds of millions across the major UGC runtimes. The operationally significant ATG risk patterns are UGC interactive runtime abuse (a script or asset distributed to a popular experience reaches every user who joins), platform-side asset-store publisher compromise, and engine-level supply-chain compromise that reaches every game built on the engine. Universally CSR-capable.

Productivity and Data Tools. Jupyter and similar notebook front-ends (JupyterLab, Google Colab, Databricks, VS Code Jupyter), Office.js add-ins (Excel, Word, Outlook, PowerPoint), browser extensions used in productivity workflows, and IDE plugin hosts (the desktop-shell plugin hosts re-appear here in their productivity application). Productivity runtimes are CSR-capable through extension surfaces, kernel-loaded notebook code, and add-in execution paths. Multi-language hosting is common: Jupyter hosts Python, R, Julia, and other kernels in the same notebook front-end; Office.js hosts JavaScript inside Excel, Word, Outlook, and PowerPoint; IDE plugin hosts admit Java, Kotlin, JavaScript, and native code into the same plugin runtime. Device-API exposure is moderate but the data access is high: notebooks routinely access sensitive data from corporate stores, AI services, cloud APIs, and desktop file systems. Device scale sits at hundreds of millions for the major productivity surfaces (Office add-ins, browser extensions in productivity contexts) and lower for the narrower data-tool surfaces (Jupyter notebooks, scientific dashboards). The operationally significant ATG risk patterns are plugin-marketplace publisher compromise, notebook execution of malicious code from untrusted notebooks (the pickle execution path, and notebooks that run their stored code as soon as they are opened), and add-in supply-chain compromise that reaches every Office user with the affected add-in installed. Universally CSR-capable across mainstream productivity surfaces.

5.5: Cross-Platform Patterns

The underlying engines, channels, and trust models repeat across categories.

  • The embedded browser engine pattern: a browser engine or browser-derived engine (Chromium, WebKit, Gecko) sits inside many non-browser shells: Electron in desktop applications, mobile WebViews, smart-TV runtimes, vehicle infotainment dashboards, IoT management interfaces, AR/VR display layers, and productivity-tool extension hosts. The engine carries its full language-level capability profile into every host. The browser-specific defensive ecosystem (CSP, SRI, Permissions API, Trusted Types) does not necessarily come with it; the host shell determines what defenses surround the engine, and most non-browser hosts apply weaker defaults than the browser does. The same Chromium engine inside Chrome and inside an Electron application is the same engine, but the surrounding defenses differ substantially. That is where defensive maturity falls off: the capability travels with the engine and the defenses do not.
  • OTA and silent-update as default: OTA bundle delivery, silent firmware update, and live asset replacement are increasingly the default across platform categories: mobile hybrid frameworks ship CodePush and similar OTA channels by default, smart TVs auto-update firmware on a vendor schedule, vehicle infotainment systems update over the air, IoT management planes push firmware silently, and game runtimes hot-swap assets in active sessions. The silent-update model removes user consent from the security model. The convenience of silent update is operational; its security implication is that the population of devices any single push reaches is bounded only by the channel, not by user agreement.
  • Plugin and extension hosting as recurring trust models: plugin marketplaces appear across desktop application shells, productivity surfaces, AR/VR platforms, smart-TV ecosystems, vehicle infotainment, and game runtimes. Each marketplace is a distinct trust model: review depth varies from active human review through automated scanning down to publisher self-attestation, meaning the publisher's own signed record of how the code was built and by whom; publisher identity verification varies; and runtime constraints applied to plugin code vary. The structural pattern is the same across the categories: a centralized distribution channel admits third-party code into a host runtime, the code runs with the host's permissions, and the user trusts the marketplace by trusting the host. A compromise of any marketplace publisher account or the marketplace itself reaches every device that installs the affected extension.
  • Device-scale concentration vs physical-world consequence per device: the browser and mobile categories together account for the overwhelming majority of Client Runtime devices in deployment. The vehicle, IoT, and control-system categories together account for the largest physical-world consequence per device. A billion-device population at moderate per-device consequence and a tens-of-millions population at the highest per-device consequence are different problems, and they call for different defensive priorities.
  • The defensive-maturity falloff outside the browser: the browser-specific defensive ecosystem (CSP, SRI, the Permissions API, Trusted Types, COOP/COEP, the Origin model) constrains a meaningful subset of the language-level capabilities and the platform-level conditions inside the browser. Outside the browser, the analogs are largely absent. Mobile platforms have App Transport Security and the network security config; desktop application shells, appliances, IoT, vehicles, control systems, AR/VR, game runtimes, and most productivity surfaces have no comparable layer.

5.6: Defense Across Platforms

The browser's platform-level defenses are built around the browser's own process model. The renderer sandbox isolates the browser's renderer process; it has no analog in IoT firmware that runs management dashboards with broad system privilege, in a vehicle infotainment shell, or in a desktop application shell that exposes operating-system APIs to its renderer. The same-origin policy and CORS enforce boundaries between origins; there are no boundaries to enforce inside a Lua UGC runtime, an Electron application that calls any host by default, or an HMI runtime that talks to a control-system network.

Subresource Integrity pins the integrity of scripts the browser's fetch pipeline loads; OTA-delivered bundles in mobile, vehicle, and IoT systems have no equivalent integrity primitive at the runtime layer. The Permissions API gates sensitive APIs inside a permissions-grant model the host shell maintains; the broader device-API surfaces in mobile, vehicle, IoT, and control-system platforms have no comparable platform-level layer. Extension-store review constrains plugin admission inside browser ecosystems; the analogous marketplaces in desktop, productivity, AR/VR, smart-TV, vehicle, and game ecosystems run on weaker review depth.

The three patterns named in the language-level analysis apply at the platform level, with platform-specific implementation challenges added at each category.

  • SSoT for runtime resources: each platform fetches and applies resources through platform-specific delivery channels: an OTA bundle channel on mobile and vehicle, a plugin marketplace on desktop and productivity, an asset CDN on game UGC, a firmware OTA on smart-TV and IoT, an extension store on browser. At the platform level the SSoT is a manifest service that observes the platform's resource-loading paths and reconciles fetched content against the reference. Implementation challenges are platform-specific: an OTA-delivered bundle's authenticity must be verified against the SSoT before runtime acceptance; a vehicle infotainment OTA channel needs its own source of truth for what a valid update is, held separately from the signed build record the OTA service supplies for itself; a plugin marketplace needs an SSoT reference for each published version that the host runtime checks at install and load time.
  • Content-swap detection: at the platform level, content-swap detection has to integrate with each platform's distribution boundary. A plugin marketplace must enforce content-swap detection at the marketplace boundary so a compromised publisher account does not push divergent content to every installed instance. An IoT management dashboard needs a detector at the runtime boundary that catches an upstream-delivered update diverging from the deployed reference. A smart-TV firmware OTA channel needs a detector that reads the new firmware against the SSoT before runtime acceptance. The detection method is the cross-platform invariant; the integration into each platform's resource-loading and resource-applying paths is the per-platform work.
  • In-memory anti-manipulation: at the platform level, the implementing code differs across categories. A vehicle infotainment runtime needs an anti-manipulation layer that operates inside the embedded browser engine, with the shell exposing the instrumentation it requires. A Roblox-style UGC runtime needs anti-manipulation that distinguishes the host engine's runtime state from the user-script runtime. An embedded browser engine in a non-browser shell needs a Permissions-API equivalent that the shell exposes for the shell's own non-browser APIs. The architectural pattern is one across the categories; the per-platform implementation work is what the pattern asks for. The same three patterns answer Malice Without Malware at the platform level. Defenses purpose-built for client-side surfaces have to come from the runtime itself, not from upstream registry, build, or pre-delivery controls; at the platform level, that means applying the three architectural patterns to each platform category.