Web and Mobile Security experimental

Web and Mobile Security From a static document viewer to a scriptable, sandboxed, cellular-connected attack surface: closing the CyBOK Web and Mobile Security gap. The Web Platform's Scripting Turn. How the browser went from a static document viewer to a scriptable platform, and why the same-origin policy became the first security boundary that mattered.. State correctly what NCSA Mosaic could and could not do in 1993.. Analyze LiveScript's 1995 renaming to JavaScript and its 1997 standardization as ECMAScript.. Explain why the same-origin policy exists and what it does and does not protect.. Mosaic, 1993, LiveScript to JavaScript, 1995, ECMA-262, 1997, Same-origin policy From a document viewer to a scriptable platform National Center for Supercomputing Applications (NCSA) Mosaic, released in 1993, was the first browser to popularize inline images alongside text. It had no scripting engine of any kind. A Mosaic page was, functionally, a formatted document: markup in, rendered layout out, nothing executed on the user's behalf beyond that rendering step. That changed in 1995. Netscape Communications, founded by Mosaic's own lead developer Marc Andreessen, recruited Brendan Eich to build a scripting language for Netscape Navigator 2.0. Eich's language shipped in beta under the internal name LiveScript, was renamed JavaScript within the same beta cycle, and was submitted to the European Computer Manufacturers Association, later renamed Ecma International (ECMA), in November 1996 for formal standardization. ECMA-262, the resulting ECMAScript specification, was published in 1997, four years after Mosaic's own release. Why scripting demanded a security boundary A document viewer with no executable content has a narrow attack surface: a rendering bug can misdraw a page, but it cannot, on its own, make a network request on the user's behalf or read another site's data. A scriptable platform is a different proposition entirely. Once a page's own code can issue requests and read responses, the platform needs a rule for what that code is allowed to read and where it is allowed to send data. That rule is the same-origin policy. An origin is the triple of scheme, host and port. The same-origin policy restricts a script's ability to read data returned from a different origin than the one that served the script, even though the script can often still send requests to other origins. This is a deliberately narrow, retrofit rule: it was not part of the platform's original 1993 design, because there was no code to restrict in 1993. It was added because scripting made restriction necessary. The pattern that recurs through this entire course: a platform's capability grows first, and its security boundary is added afterward, in response. Module 1 shows the same pattern one layer down, at the operating-system process level; Module 3 shows it again with WebAssembly. A precise correction A frequently repeated but inaccurate version of this history claims Mosaic itself shipped an early scripting or ECMAScript-like engine. It did not. ECMAScript could not have existed in Mosaic, since the ECMA-262 specification postdates Mosaic's release by four years, and the language it standardizes, JavaScript, did not exist until Netscape Navigator 2.0 in 1995. Getting this sequence right matters for this course's own credibility and for understanding why the same-origin policy exists at all: it is a response to a capability (scripting) that arrived after, not with, the web's first popular browser. Further reading See the course's own References section for NCSA's official Mosaic history page and the ECMA-262 specification text. The diagrams in this course read left to right (LR), following Mermaid's own flowchart direction keyword. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Browser Process Architecture and Site Isolation. Why modern browsers put different sites in different operating-system processes, and what that buys a defender that same-origin checks alone cannot.. Explain what Site Isolation actually isolates and from what.. Analyze how Spectre-class side channels informed the decision to isolate at the process, not just the same-origin-check, level.. Describe how Chrome's Android sandbox layers on top of the OS's own app sandbox.. Multi-process browsers, Site Isolation, Reis et al. 2019, Spectre and process boundaries, Android sandbox layering From a logical rule to a physical boundary The same-origin policy (Module 0) is a logical rule enforced by the browser's own JavaScript engine: a script simply is not permitted to read another origin's response data. For most of the web's history, that logical enforcement was considered sufficient, because same-origin data for different sites often lived in the same Operating System (OS) process, and the only way to reach it was through the JavaScript engine's own, enforced rules. Site Isolation, described by Reis, Moshchuk and Oskov in their 2019 USENIX Security paper, changes that assumption. Rather than trusting the logical rule alone, Site Isolation puts pages from different sites into different operating-system processes, each running inside its own sandbox that restricts what that process is permitted to do at the OS level. Site Isolation reached default enablement for all sites on desktop Chrome in Chrome 67 (2018), and for sites users log into on Android in Chrome 77 (2019); Android's rollout covers a subset of sites, reflecting mobile hardware's tighter memory and performance budget. Why a logical rule stopped being enough Speculative-execution side-channel attacks, of which Spectre is the best known, read data that is simply present in the same address space as the attacking code, regardless of what the JavaScript engine's own same-origin rules say a script is permitted to explicitly request. A same-origin check can prevent a script from directly asking for another origin's response; it cannot prevent a side channel from timing-attack-reading bytes that happen to sit nearby in the same process's memory. The only complete fix is to make sure that data is not in the same process at all. That is what Site Isolation buys: not a stronger logical rule, but the physical absence of the other site's data from the attacking process's address space. Layering on mobile On Android, Chrome's own sandbox sits on top of, not instead of, the Android app sandbox that already isolates every installed application from every other. Chrome's helper processes (renderers, isolated services) run as Android Services, each assigned an ephemeral user identifier (UID) by the OS, placed inside an isolated_app SELinux domain that blocks access to virtually all system services, devices and most of the filesystem. This is the same layering principle Module 5 revisits for mobile applications generally: a general-purpose OS sandbox, with a narrower, purpose-built sandbox layered on top for a specific, high-risk component. No single layer in this table claims to be sufficient alone. Each exists because the layer above it has a specific, known class of attack it cannot stop by itself. This is the defense-in-depth argument Module 2 makes explicit and quantitative. The diagrams in this module read top-down (TD), following Mermaid's own flowchart direction keyword; JavaScript (JS), the language Module 0 traced from LiveScript through ECMAScript standardization, is the same engine whose same-origin rule this module builds a physical boundary underneath. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Codebase Scale and the Defect-Density Argument. Why a multi-million-line browser codebase almost certainly contains undiscovered defects regardless of engineering quality, and why that fact, not a specific bug count, justifies isolation as a design principle.. State Chromium's approximate current codebase scale and why exact figures vary by counting methodology.. Apply historical defect-density estimates to compute a plausible latent-defect range for a codebase of a given size.. Explain why isolation is a defense-in-depth response to an irreducible defect rate, not a claim of zero defects.. Chromium's scale, Defect-density estimates, Latent-defect arithmetic, Isolation as defense in depth How big is a modern browser, really Chromium's own codebase is commonly cited at approximately 35 million lines of code, though the exact figure depends heavily on counting methodology: whether tests, generated files, comments, and the many bundled third-party libraries (V8, Skia, WebRTC, SQLite, the International Components for Unicode (ICU) library and others) are included or excluded. Repeated independent analyses over recent years place the core project itself, excluding third-party code, somewhere in a 15 to 25 million line range. No two sources agree exactly, and that disagreement is itself informative: at this scale, even measuring the codebase precisely is nontrivial. What defect-density research actually says Software defect density, conventionally expressed as defects per thousand lines of code (KLOC), has been studied across many projects and decades. Reported historical figures vary widely by study: Akiyama's early estimate was around 23 defects per KLOC; McConnell's commonly cited range spans roughly 1 to 25 defects per KLOC depending on process maturity; Chulani reported approximately 12. A 2013 scoping study surveying 109 projects across 19 papers found a mean post-release defect density of 7.47 per KLOC, with a median of 4.3 and considerable variance; the same study found that larger, more mature open-source projects tend toward lower defect density than smaller ones, not higher. The arithmetic, and its honest limits Even at a genuinely good rate, 1 defect per KLOC, a codebase of 20 million lines implies an order-of-magnitude estimate of roughly 20,000 latent defects. This is not a precise forecast for any specific codebase, including Chromium's; it is an illustration of why "we tested it thoroughly" cannot, at this scale, be read as "it has no exploitable defects left." No credible, citable source gives a single precise defect-density figure for Chromium specifically, and this course does not invent one. What the research does support, robustly, across every study cited above, is that a multi-million-line codebase almost certainly contains some number of undiscovered defects, regardless of how disciplined the engineering process is. Why this justifies isolation, not alarm This module's argument is not that browsers are unsafe to use. It is that isolation (Site Isolation, process sandboxing, the same-origin policy, mobile app sandboxes) should be understood as a deliberate, permanent response to an irreducible, nonzero defect rate at this scale, rather than a temporary measure pending some future point at which all defects are found. Defense-in-depth exists precisely because no single layer, however well engineered, can be assumed complete. That framing carries forward directly into Modules 3 through 8, each of which examines a place where an isolation layer is newer, thinner, or entirely absent. A rigorous course does not need a fabricated precision it cannot support. Presenting a verified range (1 to 25 defects per KLOC across cited studies) is more honest, and more useful for reasoning under uncertainty, than asserting an invented single number for a codebase this course does not have primary access to measure directly. The diagrams in this course read left to right (LR), following Mermaid's own flowchart direction keyword. A team acting on the verified 1 to 25 defect-per-KLOC range cannot treat it as a single point estimate; instead the range should set the boundaries of a resourcing decision, with the upper bound justifying deeper review budget for the highest-risk subsystems (the rendering and network stacks this module already named) and the lower bound setting a realistic floor for what even a mature, heavily reviewed codebase still contains after release. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Modern Web Runtimes: WebAssembly, WebCL's Failure, and GPU Compute. How the web platform added a new, near-native execution runtime (WebAssembly) safely, why an earlier attempt at general-purpose compute (WebCL) failed to gain adoption, and what replaced it for GPU workloads.. Describe WebAssembly's validate-then-sandbox execution model.. Explain why WebCL failed to achieve browser adoption despite a published specification.. Distinguish WebGPU's role from WebCL's abandoned scope.. WebAssembly's security model, WebCL, 2014 to abandonment, WebGPU as successor, Software fault isolation A new capability needs a new boundary, again Module 0 traced how scripting arrived after the browser's original design and required the same-origin policy in response. WebAssembly repeats that pattern at a different layer. It lets a browser execute near-native-speed code, typically compiled from languages such as C++ or Rust, without granting that code native-level trust. Its security model has two stages: validation, a type-checking pass over the module before anything runs, and sandboxed execution, isolating the running module from the host system by default. A WebAssembly module cannot perform file I/O, open a network socket, or read another origin's memory unless the host application explicitly imports a capability that allows it. This general approach, restricting what a piece of untrusted code can touch regardless of what the code itself contains, is known as software fault isolation. A parallel attempt that failed: WebCL Not every proposed web runtime succeeds. The Khronos Group published the WebCL 1.0 specification in 2014, intended to bring general-purpose Graphics Processing Unit (GPU) compute directly to the browser, extending the earlier, narrower WebGL graphics API. WebCL was never natively implemented in a shipping release of any major browser, Chrome or Firefox included; its official GitHub repository is now archived, with no active development. WebCL is a useful, concrete lesson precisely because it shows that a published, technically complete specification is not sufficient by itself to become part of the platform. Vendor implementation, not specification existence, is what makes a runtime real. What replaced WebCL's ambition WebGPU eventually filled the gap WebCL left, but as a separately designed API rather than a revival of WebCL itself, reaching stabilization in Chrome in 2023, nearly a decade after WebCL's specification. WebAssembly and WebGPU are frequently used together for high-performance web applications: WebAssembly supplies near-native compute on the CPU, and WebGPU supplies GPU parallelism, each governed by its own security boundary. This module's throughline: every new execution capability the web platform has added, scripting, native-speed compiled code, GPU compute, has required its own purpose-built security boundary before it could be trusted. Where that boundary failed to gain adoption (WebCL), the capability itself failed to gain adoption alongside it. Boundary and capability travel together, or the capability does not ship. Why this module matters beyond the browser The lesson WebCL's failure teaches extends past the browser entirely: a specification's technical completeness is necessary but never sufficient for adoption, because adoption ultimately depends on vendors choosing to invest scarce engineering effort in shipping and maintaining an implementation. WebAssembly succeeded where WebCL failed not because its technical design was inherently superior in every respect, but because every major browser vendor judged the investment worthwhile and shipped a conforming implementation within a comparable timeframe of each other, which is itself a coordination outcome, not a purely technical one. The diagrams in this course read left to right (LR), following Mermaid's own flowchart direction keyword. The minimum viable product (MVP) phase of the WebAssembly (WASM) standardisation effort deliberately excluded threading and garbage-collection integration from its initial scope, a sequencing choice that let the security-critical sandboxing and validation boundary ship and stabilise first, with capability extensions layered on afterward once that boundary had already been reviewed and hardened in production across every major browser engine. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Real-Time Communication and the WebRTC Leak. How WebRTC's peer-to-peer design can disclose a user's real IP address even through an active VPN, and why the mismatch between network-layer tunneling and application-layer STUN requests causes it.. Explain what a STUN request is and why WebRTC uses one.. State why a VPN's network-layer tunnel does not automatically cover an application-layer STUN request.. Assess the scope of browser-level mitigations for the WebRTC leak and their limits.. WebRTC and STUN, The 2015 disclosure, VPN layer mismatch, Mitigations and their limits A privacy tool with a layer it does not cover WebRTC lets a browser establish a direct, peer-to-peer connection with another browser, for video calls, screen sharing, or file transfer, without routing media through a central server. To make that direct connection possible across the network address translation most users sit behind, WebRTC issues a Session Traversal Utilities for Network Address Translation (NAT) (STUN) request, which discovers the Internet Protocol (IP) address a peer can actually be reached at, including the address assigned by the user's own Internet Service Provider (ISP). Daniel Roesler first publicly documented, in 2015, that a website can trigger this STUN request via JavaScript, with no permission prompt and no visible warning, and receive the user's real IP address in the response, even when the user believes a Virtual Private Network (VPN) is hiding it entirely. Why a VPN does not automatically stop this A VPN operates at the network layer: it tunnels the device's outgoing network traffic through an encrypted connection to the VPN provider, substituting the provider's IP address for the network's routing purposes. WebRTC's STUN request is issued by the browser's own application-layer implementation, and depending on how the operating system and browser resolve and route that specific request, it can reach the STUN server outside the VPN's tunnel entirely. The two mechanisms operate at different layers of the network stack, and nothing in the VPN's design automatically extends its protection to this specific application-layer behaviour. Al-Fannah's peer-reviewed paper, "One Leak Will Sink a Ship: WebRTC IP Address Leaks," documents this scope mismatch and its consequences in detail. Mitigations, and their limits Not every browser behaves the same way by default. Safari blocks local IP address disclosure by default; Brave routes WebRTC traffic through the active VPN tunnel by design. Chrome and Firefox, by contrast, expose this behaviour by default unless the user disables WebRTC entirely or installs a specific mitigation. The vulnerability has been documented and publicly known since 2015; its persistence in default configurations a decade later is itself a data point about how long a known, documented privacy leak can remain unaddressed by default when it requires an explicit, non-default choice to fix. Connect this back to Module 1: Site Isolation protects against a compromised process reading another site's data across a process boundary. It says nothing about a legitimate, permitted network operation, like a STUN request, that a page's own process is allowed to issue as part of its normal function. Isolation protects against unauthorized reads; it does not redesign what a page is authorized to do in the first place. A concrete lesson for anyone relying on a VPN for anonymity A user who assumes a VPN alone fully hides their real IP address from every website they visit is making an assumption this module's material directly contradicts, unless their specific browser and configuration are known to mitigate the WebRTC leak. The correct posture is not to distrust VPNs generally, but to verify, for the specific browser in use, whether this specific application-layer channel has been closed. The diagrams in this module read top-down (TD), following Mermaid's own flowchart direction keyword; the finding holds across VPNs (Virtual Private Networks) generally, not one specific provider's product. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Mobile Operating System Security Models. How Android and iOS each sandbox individual applications, where the two models converge, and where an app-store review process fits as an imperfect additional gate.. Describe Android's per-application UID sandbox model.. Compare it to iOS's app-sandbox model at a conceptual level.. Explain why app-store review is a useful but incomplete additional control.. Android's per-app UID sandbox, iOS's app sandbox, Permission models, App review as an imperfect gate Two platforms, one underlying design principle Android and iOS take different implementation approaches but share the same underlying principle Module 1 introduced for browsers: an untrusted unit of code, here a whole application rather than a single site, is confined to its own operating-system-enforced boundary by default. Android assigns each installed application its own distinct user identifier (UID), using standard Portable Operating System Interface (POSIX) permission separation to isolate one application's private data and process space from every other application on the device. iOS's application sandbox achieves a conceptually similar outcome through its own mechanism, confining each app's default access to its own private storage and a restricted, explicitly permission-gated set of system resources. Permissions govern access, not volume A runtime permission (Android's model) or an equivalent authorization prompt (iOS) governs whether an already-sandboxed, already-installed application may additionally access a sensitive resource, such as the camera, location, or contacts. It is important to be precise about what a permission grant actually promises: it authorizes access to a resource. It says nothing about how frequently the application accesses that resource once authorized, or how much data it transmits as a result. Module 6 returns to exactly this gap, since it is the reason instrumented measurement, not permission review alone, is the only reliable way to know what a device actually sends. Why app-store review is a real, but incomplete, layer App-store review has demonstrably caught real malicious submissions historically, which is why this course treats it as a genuine, useful layer rather than dismissing it. But review happens before publication, against a static or lightly dynamic analysis of a binary; it cannot exhaustively predict every runtime behaviour of every application under every future condition, including behaviour an app might adopt only after an update. This is the same "layer compensates for another layer's limit" pattern Module 2 made explicit for defect density: no single control in this table is presented as sufficient by itself. A common but mistaken inference: "this app is on the official store, so it must be safe." Store presence indicates it passed a review process with known, bounded limits, not that every later runtime behaviour has been verified. The correct posture combines store presence, sandboxing, and active permission review, rather than relying on any one of the three alone. Setting up Module 6 Because a permission grant does not describe data volume, the only way to actually know what a supposedly minimally configured, idle device sends is to measure it directly, under controlled conditions. That is precisely what the next module's central source, Leith's 2021 study, did. The diagrams in this module read top-down (TD), following Mermaid's own flowchart direction keyword. The practical audit question that follows from the portable operating system interface (POSIX) heritage discussed above is not whether a mobile operating system enforces process isolation at all, since both major platforms do, but where each platform's isolation boundary actually sits relative to the specific resource an application is requesting, because a boundary drawn one layer higher or lower than expected is exactly where an otherwise sound sandboxing model tends to leak. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Mobile Telemetry and Background Data. What instrumented measurement studies have actually found idle and lightly used handsets sending, and why measurement, not the permission model alone, is the only reliable way to know what a device sends.. State Leith's 2021 measured figures for idle handset data flows to platform vendors.. Explain why a permission model does not, by itself, tell a user what data is actually transmitted.. Describe why measurement methodology (device model, configuration, time window) materially changes reported figures.. The Leith 2021 study, Idle handset baselines, Permission grants versus actual transmission, Why methodology matters Measuring what a permission model cannot tell you Doug Leith's 2021 study, published as "Mobile Handset Privacy: Measuring the Data iOS and Android Send to Apple and Google," instrumented handsets under a specific, controlled condition: idle, minimally configured, with no active user interaction. This is a deliberately conservative baseline, designed to isolate what the Operating System (OS) itself sends to its own vendor, independent of whatever third-party applications a user might additionally install and use. The measured results were asymmetric. An idle Google Pixel handset sent approximately 1 Megabyte (MB) of data to Google alone every 12 hours. An idle iPhone sent substantially less to Apple over the same window, on the order of 52 Kilobytes (KB) per 12 hours. Both platforms, despite that asymmetry, connected to their respective back-end servers on a similar cadence: roughly every 4.5 minutes on average, even while the handset sat untouched. Data types observed included the hardware serial number, the Wi-Fi Media Access Control (MAC) address, and the International Mobile Equipment Identity (IMEI). A claim this course could not verify, and how it handles that The original brief for this course asked it to mention Android devices exfiltrating approximately 15 megabytes of data per day. That specific figure could not be traced to a citable, primary source during this course's research. Rather than repeat it as fact, or silently drop the topic, this module presents the verified alternative: Leith's roughly 1 MB per 12 hours (about 2 MB per day) from an idle handset to the OS vendor alone, alongside the acknowledged fact that real-world daily totals vary enormously once active applications are included. A separate, non-peer-reviewed 2024 industry experiment, for instance, measured a single popular social application alone sending over 300 megabytes in 24 hours of background operation on a freshly configured device, two orders of magnitude above the idle OS-level baseline. Why the range matters more than a single number Reported data-volume figures depend heavily on device model, OS version, exact configuration, which applications are installed and active, and the measurement window chosen. A single figure quoted without its methodology is not meaningful for comparison: "15 MB per day" answers a different, unstated question than "1 MB per 12 hours from an idle handset to the OS vendor alone." This course's own standard, consistent with Module 2's treatment of defect density, is to present the best-sourced figure available and its explicit range, rather than a more specific-sounding but unverifiable number. The broader lesson, connecting back to Module 5: a permission grant tells you an application is authorized to access a resource. It tells you nothing about volume or frequency. Only instrumented measurement, of the kind Leith performed, closes that gap, and even then only for the specific device, configuration and window actually measured. The diagrams in this module read left to right (LR), following Mermaid's own flowchart direction keyword. A security review that treats Leith's measured figures as a fixed constant rather than a lower bound specific to the devices, firmware versions and time window he instrumented will systematically underestimate current exposure, since both the volume and the destination set of idle-device telemetry are configuration- and vendor-update-dependent variables, not fixed properties of the mobile operating system (OS) category as a whole. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Advanced Mobile Threats: Zero-Click Exploitation. How commercial spyware like Pegasus defeats every layer taught so far (sandboxing, permissions, review) using a zero-click, zero-day exploit chain, and why that combination is uniquely hard to defend against.. Describe Pegasus as a commercial spyware product and its general capability model.. Explain the FORCEDENTRY exploit chain at a conceptual level.. State why zero-click, zero-day exploitation defeats permission-model and app-review defenses entirely.. Pegasus as commercial spyware, FORCEDENTRY, Citizen Lab 2021, Bypassing BlastDoor, Why zero-click changes the threat model When every prior layer is bypassed at once Modules 5 and 6 described a layered mobile security model: sandboxing, permissions, app-store review, and the gap instrumented measurement fills. Pegasus, a commercial spyware product developed by NSO Group (a name reportedly derived from its three founders' first-name initials) (NSO) and sold to government clients, is documented by Citizen Lab as capable of defeating all of those layers simultaneously, through zero-click, zero-day exploit chains that require no application installation, no permission grant, and no user action of any kind. FORCEDENTRY, disclosed by Citizen Lab in 2021 after analysis of a targeted activist's device, is the clearest documented example. It exploited an integer overflow in Apple's CoreGraphics image-rendering library, triggered by data encoded with the Joint Bi-level Image Experts Group's second compression standard (JBIG2) disguised inside a file sent via iMessage, circumventing Apple's BlastDoor sandbox, which exists specifically to isolate message-content processing from the rest of the system. Apple assigned the vulnerability the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-30860 and patched it in September 2021. Forensic analysis found the artefact CASCADEFAIL distinctive enough to attribute the installed spyware specifically to NSO Group's Pegasus. Why zero-click plus zero-day is uniquely severe A zero-day vulnerability alone, one unknown to the vendor and unpatched, might still require a user to click a link or open a file. Zero-click removes even that requirement, exploiting a vulnerability in a trusted, pre-installed system component (the messaging application itself) with no interaction whatsoever. Combined, the two properties defeat every user-facing and review-based defense this course has taught so far in one step: app-store review is never invoked because no third-party application is ever installed; permission prompts are never triggered because no new capability is being requested; user training and caution are irrelevant because there is no user action to be cautious about. What this means for a threat model For this specific class of threat, the only effective defense available at the time of exploitation was the Operating System (OS) vendor's own patch, issued after Citizen Lab's disclosure. This is a sobering, honest conclusion rather than a call to alarm: it means a security team's threat model needs to explicitly account for zero-click, zero-day exploitation as a category its existing sandboxing, permission and review controls cannot address, and to weight timely OS patching accordingly, alongside the reduction of attack surface in trusted system components wherever that reduction is achievable. The diagrams in this module read top-down (TD), following Mermaid's own flowchart direction keyword. FORCEDENTRY, tracked as CVE-2021-30860, was notable precisely because it required no user interaction of any kind: no link click, no attachment open, nothing the user could have been trained to avoid, which is the defining property of a zero-click exploit chain and the reason Citizen Lab's technical writeup was treated as a watershed disclosure rather than one incident among many. The specific parsing target NSO's chain abused, a maliciously crafted image file processed by a compression codec running with elevated trust inside iMessage, illustrates a recurring pattern this course returns to repeatedly: a component several layers removed from the user-facing application, handling input the user never explicitly requested to be parsed, is frequently where the weakest boundary in an otherwise well-reviewed system actually sits. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) The Cellular Attack Surface: Baseband and SIM Toolkit. Why the cellular baseband processor and the SIM card's own Java Card runtime sit largely outside the isolation model taught in Modules 1 and 5, and how Simjacker turned that gap into a real, remote, handset-independent attack.. Describe the baseband processor's historically privileged relationship to the application processor.. Explain what the SIM Toolkit and S@T Browser are and why they run a Java Card runtime.. Describe how Simjacker exploited this runtime remotely, over SMS, independent of handset model.. The baseband processor, Weinmann's baseband research, SIM Toolkit and Java Card, Simjacker, 2019 A second processor, a second firmware, and an older trust model Modern smartphones are, architecturally, at least two computers in one device: an application processor (AP), running the Operating System (OS) and applications this course has discussed so far, and a baseband processor (BB), running its own, separately sourced, closed firmware to handle cellular protocol communication. Ralf-Philipp Weinmann's 2010 research, "All Your Baseband Are Belong To Us," and its 2012 USENIX Workshop On Offensive Technologies (WOOT) follow-up (Best Paper), demonstrated that Global System for Mobile Communications (GSM) protocol stacks were historically written under the assumption that the network itself could never send malformed or maliciously crafted messages, and that GSM's own design does not require the network to authenticate itself to the phone. A rogue, network-side GSM interface can therefore exchange arbitrary messages with a phone's baseband processor. This matters directly to everything taught in Modules 1 and 5: Site Isolation and per-application sandboxing both operate at the application-processor, OS level. The baseband processor's firmware, historically privileged and comparatively unmonitored in its access to the application processor, sits largely outside that entire model. It is not that the AP-level isolation is broken; it is that an entire second processor exists, with an older and less scrutinized trust relationship, that the AP-level model was never designed to cover. The SIM's own runtime A second, separate attack surface sits inside the SIM card itself. The Subscriber Identity Module (SIM) Toolkit (STK) allows the Universal Integrated Circuit Card (UICC) (the physical SIM card) to proactively instruct the handset to perform actions, running within its own execution environment on the card, a Java Card runtime distinct from both the AP's OS and the BB's firmware. The S@T Browser is one such STK library, with access to a defined subset of SIM Toolkit commands. In 2019, AdaptiveMobile Security disclosed Simjacker, an attack exploiting the S@T Browser directly. A specially formatted binary Short Message Service (SMS) message, sent to the target with no required user interaction, contained S@T Browser commands instructing the UICC to retrieve the handset's International Mobile Equipment Identity (IMEI) and location via standard SIM Toolkit commands, then instructed the handset to exfiltrate that data back to the attacker in a further SMS message. Because the vulnerability lived in the SIM's own S@T Browser environment, exploitation was independent of the victim's handset model entirely, a property that distinguishes it sharply from most application-layer exploits, which are typically OS- or device-specific. Why this belongs in a complete attack-surface model A security team that stops at "we cover OS-level sandboxing, permissions, app-store review, and OS patching" has a demonstrably incomplete model. Baseband firmware and the SIM's own Java Card runtime are real, documented, exploited attack surfaces that sit outside every control this course has covered up to this point. Module 9's capstone asks learners to place both explicitly, rather than implicitly, onto a full device attack-surface map. The diagrams in this module read top-down (TD), following Mermaid's own flowchart direction keyword. The SIM toolkit (STK) attack surface Simjacker exploited in 2019 predates smartphones themselves, since STK commands have shipped on GSM-family SIM cards since the 1990s specifically to let a mobile network operator push configuration and value-added services directly onto a handset, a legacy capability almost no end user or app-store review process was ever positioned to audit. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/) Capstone: Mapping a Device's Full Attack Surface. Synthesizing Modules 0 to 8 into a single attack-surface map for a named device configuration, and closing with the surveillance and governance questions Wicker's Cornell course raises about an interconnected world.. Construct a layered attack-surface map spanning browser, OS, runtime, and cellular layers for a named device configuration.. Correctly identify each layer's defenses and known gaps, attributing them to the module that taught them.. Connect the course's technical material to the broader privacy and governance questions raised by Wicker's course.. Attack-surface mapping method, Layer-by-layer synthesis, Wicker's surveillance and governance framing, Where the course's own gaps remain Assembling the full map Nine modules have each taught one layer of a modern device's attack surface: the browser's scripting engine and same-origin policy (Module 0), process-level Site Isolation (Module 1), the defect-density argument that makes isolation necessary in the first place (Module 2), newer runtimes like WebAssembly and the cautionary tale of WebCL (Module 3), the WebRTC leak that bypasses a user's own privacy tooling (Module 4), the mobile Operating System (OS) sandboxing and permission model (Module 5), the measurement gap that model leaves open (Module 6), zero-click exploitation that defeats every user-facing and review-based control at once (Module 7), and the baseband and SIM Toolkit layers that sit outside the OS-level model entirely (Module 8). The capstone's task is synthesis, not new material: produce a single, layered attack-surface map for one named device configuration, correctly attributing each layer's defense, and each layer's documented gap, to the module that taught it. Why this is a security question and a governance question at once Every gap this course mapped, a WebRTC leak defeating a VPN's stated purpose, a mobile OS quietly sending baseline telemetry a permission model never surfaces, a Subscriber Identity Module (SIM) card remotely instructed to exfiltrate a user's location, is simultaneously a technical fact and a concrete instance of a much older question: what should an interconnected world's networks and devices be permitted to know about the people who use them, and who decides. Stephen B. Wicker's CornellX course, "Wiretaps to Big Data: Privacy and Surveillance in the Age of Interconnection," addresses that question directly at the policy, legal and societal level, exactly where this course's own material sits at the technical level. The two are not separate subjects that happen to share a general theme; they describe the same underlying phenomenon from two different, complementary angles, and this course recommends Wicker's material as the natural continuation for anyone who wants the governance and policy framing this course itself does not attempt to provide. An honest closing limit Module 2's defect-density argument applies recursively to this course itself: completing all ten modules produces a well-documented, historically grounded map of known layers and known, cited incidents as of this course's writing. It does not, and cannot, prove that no further layer exists. New runtimes, new baseband designs, or new SIM technologies could introduce attack surfaces this course has not covered. The correct posture, consistent with everything taught here, is to treat this map as the current best understanding, not a final, closed inventory. Where WebAssembly fits in the finished map Module 3's WebAssembly (WASM) material earns its place in the finished attack-surface map alongside every other layer this course taught: it is a newer execution capability whose security boundary (validation, then sandboxed execution) had to be purpose-built before browsers could trust it, following exactly the pattern Module 0 first established for scripting itself. A complete device attack-surface map names WASM's boundary explicitly rather than treating "the browser" as a single undifferentiated layer. The diagrams in this module read top-down (TD), following Mermaid's own flowchart direction keyword. Placing WASM's validation-then-sandbox boundary onto the same map as the virtual private network (VPN) leak path, the mobile sandbox boundary and the baseband and SIM surfaces studied in Modules 4 through 8 is the capstone's actual deliverable: not a longer list of individually memorised facts, but one continuous boundary diagram a security team could hand to a new engineer on their first day. Related CCI capabilities Computer Architecture (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/computer-architecture/). Optics Primer Series (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/optics/). Maths Refresher Series, Finance (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/maths-finance/). System Dynamics (Course): (https://www.cambridgecyberinternational.com/en/insights/academy/system-dynamics/). CCI Lab: Run it, build with it, read the thinking, reuse the data. (https://www.cambridgecyberinternational.com/en/insights/lab/)