Named Concepts | Attack the Glass

The named concepts of Attack the Glass, as the corpus registers them. Definitions are reproduced from the source and are not rewritten here.

Adversarial Asset Cycling

The adversary's four-stage lifecycle (acquire, run, abandon, re-emerge) that inherits existing trust and exploits ownership opacity.

Technical Whitepaper12.3: The Adversarial Asset Cycling Pattern

The Allowlist Fallacy

Adding a source to an allowlist, a domain, CDN, package, or endpoint approved as trusted, is treated as if it also approved everything that source will return. But an allowlist authorizes an address, not the content it ships, and that address can lawfully return different or mutated content on any later load. Standing trust in the source is mistaken for verification of the payload.

Technical Whitepaper1.9: The Allowlist Fallacy

The Application Blueprint

What ships is a plan, not a finished product. The shipped application is a loader that assembles itself from parts it does not control. (Static: the reader's comfortable assumption, set up on purpose so it can be broken.)

Technical Whitepaper1.5: The Application Blueprint

The ATG Vulnerability

ATG begins with an architectural choice: applications assemble themselves on the user's device. It becomes a vulnerability when that architecture meets a supply chain. It becomes an operational threat when an adversary holds a position in that supply chain.

Technical Whitepaper2.9: The ATG Vulnerability Defined

The Client Runtime

The host on the user device where rendering and execution happen. Replaces the retired "CRE / Client Runtime Environment." The CSR-capable qualifier ("CSR-capable Client Runtime") marks the in-scope subset and is used only at scope-distinction moments; elsewhere, Client Runtime stands plain.

Technical Whitepaper1.1: The Client Runtime

The Client Runtime Boundary

The load-to-execute moment where a fetched artifact stops being inspectable resource and starts being executing behavior with the host's permissions.

Technical Whitepaper9.6: No Verification at the Client Runtime Boundary

Client-Side Rendering (CSR)

Client-Side Rendering: the root architectural pattern; final assembly and execution happen on the client device. It is the root architectural pattern that produces the modern Client Runtime.

Technical Whitepaper1.2: Client-Side Rendering

Code That Writes Code

Running code can generate more code at runtime, so what ultimately runs never existed to be inspected before execution.

Technical Whitepaper1.12: Code That Writes Code

The Compute Tax

To run a client-side-rendered app, the user pays, in device, bandwidth, and power, to perform the provider's computation. The provider ships a blueprint rather than a finished product, and the user's device does the manufacturing (assembly and execution) at render time. It is a tax, not a bill: an extraction with no line item and no discount, you pay more (for the CPU, the bandwidth, the electricity) and get the same product at the same price. Because the cost is diffused across billions of users and devices, the transfer is never noticed, and neither is the fortune it saves the provider. Calibration: the transfer is real and broad (device plus bandwidth plus power) but scoped, "diffused across billions," not "users pay nothing knowingly."

Technical Whitepaper1.3: The Move from Server to Client

Conscripted Trust

In client-side rendering, the application author decides which third parties the client device will trust, and encodes that decision in the App Blueprint. The device executes it. The person operating the device is not shown the list, is not asked to agree to it, cannot inspect what any entry on it returns, and cannot decline an entry without losing the application. The trust relationship is real, it is binding, and it was entered into by someone else on the user's behalf. Calibration that must survive a hostile reader: the client is not powerless. Extensions, script blockers, enterprise policy and DNS filtering all exist and all work. What none of them can do is inspect what a permitted provider actually returned, or accept a provider on conditions. The client can refuse the relationship but cannot condition it.

Technical Whitepaper1.5: The Application Blueprint 1.8: Verification Ends at Delivery

Content Swapping

The family of on-page changes ATG makes: a value, image, link, form field, or chart swapped for another.

Technical Whitepaper2.12: Content Swapping

The Cost of Free

"Free" third-party components are paid for in trust and access: adopting them grants standing execution inside the runtime.

Technical Whitepaper3.2: The Commercialization Gray Zone

D5 Effects

Deceive, Disrupt, Degrade, Deny, Destroy: the five outcome classes. Not a ramp. Each is fully capable alone, combinations are ordinary, and 01 to 05 is a stable index rather than a severity order (role labels retired 2026-08-22). Scored with an object and a reach, never with reach written into the effect.

Technical Whitepaper2.17: D5 Effects

Data as Code

Content fetched as ordinary data can become executable at the moment it is read, so inspecting it as data never reveals what it will do.

Technical Whitepaper1.11: Data as Code

The Detection Blindspot

The live face. Nothing verifies, at execution, that a fetched resource matches an authoritative reference. Static SRI is the only near-attempt, author-declared, optional, and unable to cover dynamic resources, so in practice nothing checks in real time.

Technical Whitepaper2.15: The Integrity Blindspot 14.3: Subresource Integrity: Value and Limits

The Digital Supernode

A small number of dependencies, a dominant CDN, a near-universal library, a key service, sit at hubs where millions of applications, sites, and organizations all depend on the same node. They reach that position through Herd Trust (ubiquity compounding on reputation), and that concentration of reach makes them the highest-value targets in the supply chain: control of a single Digital Supernode is not access to one app, but a position over millions at once. Calibration: "a small number of hubs," "millions of dependents", scoped to the genuinely high-reach nodes, not every popular dependency.

Technical Whitepaper2.8: The Digital Supernode

The Endemic Flaw

ATG is endemic to client-side rendering. Because the vulnerability arises from the architecture itself, composition at render time, execution on the glass, it is present, independently, in every runtime that uses the pattern: browser, mobile webview, desktop app, smart TV, kiosk, embedded panel. It is not transmitted between runtimes (they are not connected); each inherits it from the shared design. Like any endemic condition, it cannot be eradicated by treating individual cases, a per-runtime patch does not reach the pattern that produces it.

Technical Whitepaper14.6: Defenses Outside the Browser, and the Endemic Flaw

The Forensic Blindspot

The after-the-fact face. Nothing is recorded to reconstruct later: the resource was in-memory and per-session (gone on tab or browser close), encrypted in transit (network monitors see only metadata, timestamps, sizes, destinations), and non-reproducible at source. No malicious file to scan, no fake domain to block, nothing in the logs.

Technical Whitepaper2.15: The Integrity Blindspot

The Glass

The rendering surface where a runtime renders for a human. Capitalized as the named concept; lowercase for a literal pane of glass.

Technical Whitepaper2.4: The Glass: The Final Mile of Every Digital System

The Glass Beyond the Browser

The rendering surface is any surface where a runtime renders for a human; the pattern spans platforms far beyond the web browser.

Technical Whitepaper1.13: The Glass Beyond the Browser

Herd Trust

In many client-side stacks, a library, service, or technology is trusted, and included, because it is popular, well-branded, and widely adopted, not because anyone verified it. Inclusion by Reputation is the mechanism: the decision to include is made on reputation, and no verification of behavior or intent follows. Widespread use feels like herd immunity, safety in numbers, but adoption confers no safety; the trust is borrowed from the size of the crowd.

Technical Whitepaper1.8: Verification Ends at Delivery 2.8: The Digital Supernode

Integration on the Glass (IOTG)

The integration pattern that assembles the application at the moment of rendering.

Technical Whitepaper2.5: Integration on the Glass (IOTG)

The Integrity Blindspot

You cannot verify, at the moment it matters, that a resource is what it should be, neither live nor after the fact, because there is no authoritative reference for what "correct" looks like. The invisibility is structural, not a tooling oversight: monitoring inside the TLS/SSL rendering boundary, where the swap actually occurs, is not deployed at any meaningful scale today, so no single organization can simply buy its way out. Scope: this is a prevalent condition, not a universal law. It holds where no live resource source-of-truth is deployed and in-boundary monitoring is absent, the common case today.

Technical Whitepaper2.15: The Integrity Blindspot

The JIT App Blueprint

The plan is realized just-in-time at render, assembling from parts fetched live from sources the owner doesn't control. (First crack in the static picture.) Every component can pass its own integrity check while the assembly that combines them on the device is unprotected.

Technical Whitepaper1.4: Why CSR Won Chapter 2: The ATG Vulnerability Architecture

Lying in Wait

A dormant adversarial capability, pre-positioned within a genuinely legitimate, trusted dependency, sits inert and undetectable through a dwell phase, because the host really is legitimate, standard telemetry, security testing, and integrity checks all return normal, and is activated only at the chosen moment. The weapon is present but inert; the only detectable event is activation, by which time the dependent population has often grown. Calibration: "genuinely legitimate," and the dwell phase produces no adversarial signature, scoped to the cover model; this is not a claim that all adversarial infrastructure is dormant.

Technical Whitepaper7.5: Lying in Wait

Malice Without Malware

Existing defenses hunt malicious code from a malicious source. ATG produces a malicious outcome with neither, clean, legitimate code from a trusted source. There is no malware artifact to scan and no bad reputation to flag, so the tools built to catch "bad code from a bad source" never fire. The malice is real; the malware is absent. Calibration: scoped to signature and reputation-based detection, most defense, not all; behavioral and anomaly approaches are a partial exception.

Technical Whitepaper1.14: Malice Without Malware

The Manifest Illusion

Where an application loads code dynamically, generates code at runtime, or fetches parts live, a complete and accurate list of what actually runs cannot exist. The manifest defenders hold, a package list, lockfile, SBOM, or CSP allowlist, is an illusion of completeness: it records what was declared at build time, not what executes at run time, and the two diverge with nothing to reconcile them. Calibration: this holds for dynamic and CSR apps that load, generate, or fetch code at runtime, prevalent but not universal. A fully static, no-third-party, locked-CSP app can have an accurate manifest.

Technical Whitepaper1.10: The Manifest Illusion

The Missing Source of Truth

The root. There is no live, central, authoritative record of what each resource should be, so there is nothing to check against, which is why both the live and forensic faces are blind. This is the root; the other two are its consequences across time.

Technical Whitepaper2.15: The Integrity Blindspot

No Network Is Structurally Immune

Wherever a Client Runtime consumes content from any external source, ATG applies, regardless of which network connects the runtime to that source. Isolating a network relocates the supply chain rather than removing it, and isolation applied afterward does nothing about code that was already inside when the isolation began. Calibration, in the chapter's own voice: the digital supply chain inside a classified network or a hardened OT segment is significantly smaller and more controlled than the public web, and the protected-network differential is real. The protected-network case is not exempt; it is differently exposed.

Technical Whitepaper2.16: ATG Applies to All Networks, Not Just the Internet

The Open-Source Open Door

Open source is the dominant, legitimate, wide-open route by which code reaches the glass: most of what runs is third-party open-source dependency code, and contributing to or taking over a package is a low-threshold path to placement. The adversary does not bypass trust the way a backdoor does, they are handed it (Herd Trust), walking in the open door as an invited, trusted contributor or maintainer. Nothing is broken into; the door was open by design. Calibration: "most" running code is open source, true for many CSR stacks, not all; "low-threshold," not "trivial" or "always", some ecosystems have review or signing.

Technical Whitepaper9.2: The Open-Source Open Door

Origin Laundering

Once many sources are loaded into the runtime and begin interacting, it becomes nearly impossible to trace where anything came from. Origins blend, one script can derive runtime code from another source's data, so provenance dissolves and attribution fails. As in money laundering, malicious input is passed through legitimate sources until its origin is untraceable and it hides inside the clean flow. The result is a hiding place for adversarial injection with no clear trace route. Calibration: "nearly impossible," not "impossible", some provenance survives in some stacks (source maps, SRI on specific resources).

Technical Whitepaper9.4: Origin Laundering

Ownership Opacity

The visibility problem: you cannot see who owns or controls the infrastructure delivering to a Client Runtime. Owners are layered (financial, corporate, operational, personnel), there is no public registry, and there is no AML-analog notification of transfers.

Technical WhitepaperChapter 12: Ownership Opacity: The Visibility Problem

The Perpetual State Machine

The assembled app never settles, changing on two independent axes. Input-driven: state and workflow are a combinatorial function of interaction sequence plus date/time plus platform plus location plus user preferences. Part-driven: the parts themselves can change on every resource request, so even the app's function, not just its state, can change per fetch. It is never the same twice. Scope: this describes sufficiently interactive or dynamic applications, the prevalent modern case, not every app; a static, single-render page is not a Perpetual State Machine.

Technical Whitepaper1.6: The Perpetual State Machine

Placement, Access, Influence, Control

The causal chain of an operation and the rising levels of control positional quality buys; control follows position, not actor size.

Technical Whitepaper3.5: Placement, Access, Influence, and Control

Post-Load / Post-Trust Modification

Trusted, verified, in-memory data is mutated by runtime code after load; the displayed value is no longer the fetched value, and nothing re-checks it.

Remote Cache Control

The server governs the client's own local cache via Cache-Control directives, it can serve the malicious variant once (or no-store it so nothing persists), then serve clean content to any investigator. Serve-once, then clean. This is why the served resource can't be reproduced.

Technical Whitepaper2.15: The Integrity Blindspot

Runtime Anarchy

Security controls concentrate at the loading gate: CORS governs cross-origin access, CSP governs what may load and execute, SRI checks the integrity of what's fetched. But once a script clears that gate and executes, nothing governs what it may do. Within a single execution context, every script is co-equal, with full rights to read and modify shared state, the DOM, globals, other scripts' data. There is no per-script sandbox, no privilege hierarchy, no authority imposing limits. The only real interior boundaries are coarse and document-level (cross-origin iframes, sandboxed frames, workers), not per-script. Controls at the door; none in the room. Calibration: the flaw is the absence of per-script isolation within a context, not "no controls anywhere." Load-time controls (CORS/CSP/SRI) and coarse document boundaries genuinely exist; what's missing is in-context governance of behavior.

Technical Whitepaper8.4: Runtime Anarchy

The Silent Transfer

Control of a trusted asset can change hands with no technical signature. The transfer runs through non-technical channels, a company sale, a credential compromise, a maintainer or namespace transfer, a DNS repoint, none of which alter the URL, the hash, or the certificate. Everything a scanner measures stays green while the party deciding what the asset serves becomes someone else.

Technical Whitepaper12.2: The Public-Information Floor

The Static Resource Assumption

The false belief that a URL returns one fixed thing to everyone. In truth a URL resolves to a resource that can lawfully be generated per request, so the same address returns different content to different requesters, the thing was never a static file to begin with.

Technical Whitepaper2.7: The Static Resource Assumption

Supply Chain Injection

The general form of the injection: a compromise introduced anywhere upstream travels forward through composition to execute on the glass.

Technical Whitepaper2.10: Supply Chain Injection

Tailored Deception

Generative AI in the runtime produces substituted content per target, on the device, at machine speed, leaving no shared population to detect against.

Technical Whitepaper10.6: Tailored Deception

Targeted Delivery

Conditioning what a resource returns on who is asking, using the conditions any content-personalization system already uses. Selection Rules are the mechanism: the IP or geo, device, time, identity, behavior, prior intelligence, cohort and A/B rule set that decides which requester receives the swap. Precision note: the ATG-relevant vector is the ad network's own script, the header-bidding or tag loader that runs in the main page context, not the ad creative, which renders in a cross-origin or sandboxed iframe. Ad tech is one infrastructure that can resolve the rule and is explicitly not the vector.

Technical Whitepaper2.14: Targeted Delivery

The Two-Stage Attack

A hash-valid, verifiably clean script carries the attack through the runtime data it fetches at execution, not through its own code.

Technical Whitepaper2.11: The Two-Stage Attack

URL Overtrust

Treating a URL as a fixed, safe file when it is in fact a position in a supply chain, an address that can lawfully return different or mutated content on any request. The error is not merely trusting the URL too much; it is misplaced in kind: a URL is not a file at all, so the trust is extended to the wrong sort of thing.

Technical Whitepaper2.6: URL Overtrust

Weapons of Mass Deception

The convergence of ATG delivery with per-target generative AI as adversarial-influence infrastructure. Reserved for the attribution and FIMI track.