Privacy-Preserving Diagnostics and Reproducible Performance Laboratory

Full report

On this page

1. Executive Measurement and Privacy Recommendation

The engineering of high-performance local inference engines within the strict confines of browser security models necessitates a fundamental paradigm shift in telemetry and observability architectures. Traditional telemetry models rely almost exclusively on the mass exfiltration of user prompts, raw model outputs, and stable hardware identifiers to centralized analytical servers. For the TinyRustLM architecture, executing within WebAssembly (WASM) and WebGPU environments, this legacy approach is diametrically opposed to the project's foundational zero-knowledge privacy mandate. The recommended architecture establishes a strictly local, cryptographically reproducible performance laboratory that shifts the burden of proof from centralized analytics to deterministic, locally generated artifacts. Performance claims within this ecosystem must be mathematically verifiable without ever exposing the underlying user data or the semantic content of the interaction. To achieve this, the measurement system relies on the generation of exact workload identities, which are cryptographic hashes that irreversibly bind the specific model weights, tokenizer configuration, prompt geometry, and sampling parameters. These identities are then coupled with high-resolution, hardware-backed timing and memory allocation metrics gathered locally. The diagnostic apparatus must operate with statistical rigor mirroring the Criterion.rs framework, emphasizing bootstrap resampling, heavy-tail analysis, and non-parametric bounds, while strictly adhering to the scientific benchmarking protocols established by Hoefler and Belli1. Privacy is mathematically guaranteed through a multi-layered defense mechanism encompassing deterministic redaction, entropy-based secret scanning3, and the generation of bounded local support bundles that users can manually inspect and authorize prior to any external sharing. Unversioned logs, arbitrary print statements, and implicit network telemetry paths are strictly prohibited. By decoupling performance measurement from data extraction, TinyRustLM can achieve aggressive optimizations in latency, throughput, memory footprint, and energy efficiency while maintaining an absolute cryptographic guarantee of user privacy.

2. Claim Taxonomy and Evidence Levels

A mathematically rigorous performance culture requires a strict taxonomy for evaluating, documenting, and promoting code changes. A performance optimization that lacks statistical significance, relies on uncontrolled variables, or exceeds numerical regression budgets is indistinguishable from system noise and must automatically fail promotion. The taxonomy of evidence levels defines the precise boundaries of what constitutes a valid performance claim and establishes the minimum verifiable artifacts required.

Latency and throughput claims must never be reported as single favorable runs or arithmetic averages of skewed distributions. They must represent the median or specified high-percentile bounds (e.g., 95th, 99th percentiles) derived from a pre-registered statistical sample. Memory claims must rigorously differentiate between WASM committed memory, native resident set size (RSS), and WebGPU buffer allocations, as conflating these pools leads to catastrophic out-of-memory errors on constrained devices. Energy claims must specify the exact measurement vector utilized, such as the Intel Running Average Power Limit (RAPL) interface5 or ARM System Control and Management Interface (SCMI). Quality-neutral claims dictate that the exact token sequence or the numerical output hash of the inference engine remains absolutely invariant despite the underlying optimization. Finally, release-wide claims must aggregate these metrics across the entire supported platform matrix, proving that an optimization on one architecture does not regress another. Prohibited wording across all evidence levels includes any unquantified variation of "runs fast," "optimized for ARM," or "low memory footprint" without the accompanying versioned workload identity and absolute numerical baselines. Cross-compilation and emulation environments must never be presented as physical hardware evidence2.

3. Versioned Event, Trace, and Operation Schemas

The diagnostic system requires a strictly typed, versioned schema to capture operation traces without relying on arbitrary, unversioned logging that inevitably leaks sensitive data. The schema is optimized for local storage, bounded retention, and immediate serialization to JSON or a binary equivalent when compiling an authorized support bundle. The schema deliberately limits the types of data that can be recorded, enforcing privacy at the structural level.

The operation traces utilizing this schema must cover the entire TinyRustLM lifecycle comprehensively. Model acquisition and peer-to-peer import traces capture the cryptographic file validation and hashing phases without logging absolute filesystem paths. Allocation and activation traces monitor the extensive memory reservation required prior to context compilation, ensuring that out-of-memory conditions are tracked deterministically. Tokenizer initialization and prefill traces isolate the prompt processing overhead, while the decode step traces capture the autoregressive generation loop. UI render, memory retrieval, tool call, and model switch traces monitor the integration boundaries between the inference engine and the host application. Crucially, OPFS deletion and process restart traces ensure that memory freeing and cleanup operations are tracked, preventing silent memory leaks from persisting across sessions. Throughout this entire lifecycle, the schema enforces a strict omission of token values, prompt text, and payload content. The system relies entirely on bounded counts, cryptographic hashes, and categorical statuses to measure performance, guaranteeing that an exported diagnostic trace contains zero semantic information about the user's interaction.

4. Clock, Latency, Throughput, and Responsiveness Methodology

Accurate timing in a modern browser environment is severely complicated by necessary security mitigations against microarchitectural side-channel attacks. Exploits such as Spectre, Rowhammer, and SSD contention attacks rely on precise timing to infer unauthorized data8. Consequently, browsers deliberately reduce timer precision and introduce jitter, forcing the diagnostic system to rigorously define its clock semantics and navigate these constraints gracefully. Wall clock time, typically accessed via Date.now(), is subject to Network Time Protocol (NTP) adjustments, leap seconds, and user manipulation, rendering it entirely unsuitable for microsecond-level performance measurement. The monotonic clock, accessed via performance.now(), provides a continuous timeline but is artificially coarsened by the browser engine unless strict cross-origin isolation (COOP/COEP) headers are present on the host document8. When these headers are active, timer precision is partially restored, but cross-process correlation becomes complex. For instance, when correlating events between a dedicated Web Worker executing the WASM inference loop and the main thread managing the DOM, timing offsets must be meticulously calculated using performance.timeOrigin to align the discrete monotonic timelines12. For GPU execution, the WebGPU specification outlines the timestamp-query extension, allowing command encoders and compute passes to write high-resolution timestamps directly to a GPUQuerySet upon the completion of a shader pipeline13. However, timestamp-query is frequently disabled, heavily quantized, or restricted behind developer flags in browsers due to the severe timing attack risks associated with exposing raw GPU cycle counts to JavaScript10. The diagnostic system must gracefully degrade when hardware timestamps are unavailable, falling back to the User Timing Level 3 API (performance.mark and performance.measure), which allows for custom start times and the attachment of detailed metadata payloads17. The system must explicitly label the timer resolution and precision limitations in the diagnostic receipt to prevent analysts from drawing false conclusions from quantized data. Latency metrics must be isolated into discrete distributions rather than reported as a single, misleading arithmetic average. Cold acquisition measures the latency of loading model bytes from the network or cold disk, while warm acquisition measures the vastly different latency of loading from the HTTP cache or the Origin Private File System (OPFS). Hash and structural validation phases measure the CPU overhead of cryptographic verification prior to execution. Activation and context assembly measure the memory allocation and buffer staging required before inference can begin. Time to first generated token (TtFT) and time to first rendered token are critical responsiveness metrics, capturing the latency of the prefill phase and the main-thread rendering pipeline. Inter-token latency and steady decode throughput, measured strictly in tokens per second, must be calculated after the initial token generation to exclude prefill skew from the steady-state distribution. Long-context decode measures the performance degradation as the Key-Value (KV) cache expands toward the maximum context window. Responsiveness metrics dictate that performance optimization within the inference engine cannot render the host application or chat surface unusable. Main-thread long tasks must be measured using the Long Animation Frames (LoAF) API to detect execution blocks that monopolize the UI thread for periods exceeding 50ms19. Event-loop delay, scroll stability, rendering cadence, and worker message backlogs must be continuously monitored. If cancellation requests take longer than a defined microsecond threshold to halt the generation loop and yield the thread, the performance optimization fails the responsiveness gate, regardless of its raw throughput improvements.

5. Complete Memory-Accounting Model and Formulas

Memory accounting in a sandboxed browser environment requires a sophisticated, layered approach, as raw physical memory allocation is largely abstracted by the JavaScript virtual machine. The system must distinctly account for artifact bytes (the raw size of the serialized model weights on disk or network), the physical store (the footprint within the OPFS virtual filesystem), and the logical composition within active memory. For JavaScript heap and DOM memory, the diagnostic system leverages the performance.measureUserAgentSpecificMemory() API, provided the application operates within a cross-origin isolated context11. This modern API returns a promise that resolves post-garbage-collection, providing a more accurate estimation than legacy metrics. The returned object contains the total bytes allocated and a breakdown array detailing attribution across specific iframes and dedicated workers22. For the WASM execution environment, memory tracking is highly deterministic but governed by strict architectural limitations. WASM linear memory currently operates on a 32-bit addressing limit, restricting it to 4GB of addressable space. Furthermore, WASM memory can only grow via the Memory.grow instruction; it cannot shrink or return pages to the host OS until the entire module is destroyed24. TinyRustLM mitigates this by utilizing the talc allocator, a highly optimized dlmalloc-style linked-list allocator with boundary tagging specifically designed for WASM environments25. By compiling the talc allocator with the counters feature flag enabled, the system can precisely extract internal allocation statistics. This provides visibility into the total allocated bytes for live tensors, the KV cache, and worker stacks, as well as tracking heap fragmentation and peak committed memory28. When executing via native companion applications that bypass browser limitations, the system utilizes operating system APIs to monitor true physical memory. On Linux, the system parses the /proc/self/smaps\_rollup file, calculating the Unique Set Size (USS) as the sum of the Private\_Clean and Private\_Dirty page counts30. This provides an exact measurement of the memory exclusively utilized by the process, excluding shared libraries. On Windows, the system invokes the GetProcessMemoryInfo API to retrieve the PROCESS\_MEMORY\_COUNTERS\_EX structure, extracting the PrivateUsage and PeakWorkingSetSize parameters31. WebGPU memory accounting requires maintaining a rigorous shadow ledger. The system must manually track all device.createBuffer and device.createTexture calls to monitor GPU buffer allocations, staging buffers for host-to-device transfers, and readback buffers for device-to-host synchronization. Because browsers do not natively expose a unified "free GPU memory" API due to the severe fingerprinting and side-channel risks associated with exposing global VRAM state10, the shadow ledger is the only mechanism to estimate remaining capacity. Any memory metric that is theoretically relevant but technically unavailable to the browser sandbox must be explicitly labeled as UNAVAILABLE\_IN\_SANDBOX rather than inferred through heuristic guesswork.

6. Energy and Thermal Evidence Levels

Energy efficiency is a primary constraint for local inference, particularly on battery-powered mobile and laptop devices. The diagnostic system defines strict levels of energy measurement evidence, which are heavily dependent on the execution environment and the permissions granted to the process. The highest fidelity programmatic measurement relies on OS-level energy counters. For Intel architectures, the system interfaces with the Running Average Power Limit (RAPL) framework via the Linux powercap sysfs interface located at /sys/class/powercap/intel-rapl. RAPL utilizes hardware model-specific registers (MSRs) to expose energy consumption directly in microjoules (energy\_uj)5. To isolate the processor's energy consumption, the system reads the intel-rapl:0 (package) zone, which aggregates the power consumed by the core subzone (the processor cores) and the uncore subzone (integrated graphics and memory controllers)33. On ARM architectures, the equivalent System Control and Management Interface (SCMI) provides platform power domain measurements via the arm\_scmi\_powercap driver34. For lower-level instruction profiling on Linux native testbeds, the system utilizes the perf\_event\_open system call to read hardware counters such as PERF\_COUNT\_HW\_CPU\_CYCLES and PERF\_COUNT\_HW\_INSTRUCTIONS35. Because physical hardware counters are limited and subject to time-multiplexing by the kernel when multiple events are requested, the raw counter values may not represent the entire execution period. The diagnostic system must read the time\_enabled and time\_running fields from the event format. If the time enabled is strictly greater than the time running, the raw count must be scaled to reflect the true execution cost using the following formula37: [Figure omitted from source export] For pure browser execution where native RAPL sysfs files and perf hardware counters are inaccessible due to sandbox restrictions, programmatic energy measurement is inherently restricted. Battery discharge APIs, where exposed, are far too coarse and heavily delayed to provide accurate per-inference energy metrics. Therefore, browser-only energy claims are strictly prohibited by the taxonomy. Energy regression testing must occur in the native companion testbed or via external hardware wall-power meters synchronized with the test execution. To isolate the specific energy cost of the inference workload, the system must perform rigorous idle subtraction. This involves measuring the baseline power draw for a stabilization period while the screen is on but the inference engine is idle, running the inference workload for a statistically significant duration, and subtracting the integrated baseline energy from the total run energy. Thermal stabilization periods must be enforced between runs to prevent dynamic frequency scaling (thermal throttling) from artificially extending runtimes and skewing the energy calculations.

7. Workload Identity, Suite, and Preregistration Contract

Comparing two performance runs requires an absolute, mathematically verifiable guarantee that the workload remains identical. The Workload Identity Contract enforces this strict equivalence by generating a cryptographic identity for every test execution. This identity binds the exact model parameters, quantization scheme, LoRA adapters, tokenizer configuration, and templating logic into a single hash. To preserve privacy, the exact prompt text is hashed (e.g., using SHA-256) and kept strictly private, while the prompt token count and output token cap are exposed in the public receipt. Sampling parameters (temperature, top-p, fixed seed) and the precise state of the KV cache are bound to the identity. Finally, the execution environment—including the thread count, WASM backend, browser version, and OS—completes the contract, ensuring that comparisons are only made between identical configurations. The workload suite defines the standardized tests required for code promotion. Tiny fixtures with minimal vocabulary are used for rapid instrumentation and automated unit testing. One admitted real model (e.g., a heavily quantized 8B parameter network) serves as the macro-benchmark. The suite includes:

• Short and long prefill bounds to stress the context compiler.
• Repeated multi-turn chats with exact prefix reuse to measure KV cache hit rates.
• Complete cache misses forcing full recomputations from zero.
• Memory pressure scenarios simulating heavily constrained device limits.
• Cancellation latency tests interrupting the steady decode phase.
• Cold restarts bypassing all OS, browser, and hardware caches.

Preregistration is mandatory to prevent p-hacking and favorable-run selection. Before observing comparative results, engineers must freeze their hypotheses and record the baseline and candidate identities. The primary endpoint (e.g., median steady decode throughput in tokens per second) must be declared. The sample size method, warm-up iterations, and randomization order must be established. Outlier exclusion rules (such as discarding runs demonstrably compromised by unexpected OS background tasks) must be defined upfront, ensuring that the statistical analysis remains objective and mathematically sound.

8. Statistical Design and Regression Decisions

Performance metrics in complex, multi-layered systems like a browser executing WASM exhibit severe heteroscedasticity, heavy right-tails, and highly non-normal distributions due to garbage collection pauses, JIT compilation heuristics, thermal throttling, and OS thread scheduling2. Consequently, assuming normal distribution and using arithmetic means for latency or throughput is mathematically flawed and explicitly discouraged in scientific benchmarking1. The statistical treatment for TinyRustLM follows the methodology of the Criterion.rs framework39 adapted to the rigorous scientific benchmarking protocols established by Hoefler and Belli2. The analysis requires nonparametric statistics to avoid assumptions of normality. For summarizing rates (e.g., throughput measured in tokens per second), the system mandates the use of the harmonic mean, as arithmetic means mathematically skew rate-based comparisons2. For summarizing costs (e.g., latency measured in milliseconds), the median (50th percentile) and high percentiles (95th/99th) are required to capture the heavy tails introduced by system jitter. Outlier classification utilizes a modified Tukey's fence methodology40. The Interquartile Range (IQR) is computed from the sample, and values falling below [Figure omitted from source export] or above [Figure omitted from source export] are classified as mild outliers, while those beyond [Figure omitted from source export] are classified as severe outliers42. Outliers are documented in the diagnostic bundle but are not automatically discarded unless they can be traced to predefined preregistration exclusion rules. Confidence intervals must be calculated using bootstrap resampling to provide tight, non-parametric bounds on the median and harmonic mean39. To evaluate practical significance alongside statistical significance, effect sizes are computed. A strict regression threshold is enforced for all promotions: if the lower bound of the candidate code's confidence interval overlaps with or falls below the upper bound of the baseline code's confidence interval, the performance claim is rejected as indistinguishable from system noise. Favorable-run selection—cherry-picking the fastest iteration from a distribution—is strictly prohibited and violates the auditing standard.

9. Cold, Warm, Steady, Restart, and Cache-State Definitions

A performance metric in a modern computing environment is meaningless without precisely defining the state of the system caches. The diagnostic laboratory rigorously defines and controls these states to ensure reproducible benchmarking. Cold State: Achieving a true cold state requires a complete process restart and extensive cache invalidation. The OS page cache must be dropped (e.g., via /proc/sys/vm/drop\_caches on native Linux environments). The browser HTTP cache and Service Worker caches are programmatically cleared. The WASM compilation cache and WebGPU shader pipeline caches are bypassed. In this state, the model is entirely nonresident in memory, and the execution trace will capture the full latency of network/disk I/O and JIT compilation. Warm State: In a warm state, the model bytes already reside in the OPFS, the HTTP cache, or the OS page cache. The WASM module is already compiled, optimized, and instantiated by the browser engine, avoiding the massive V8 or SpiderMonkey compilation overhead. WebGPU shader pipelines are resident in the driver cache. However, the KV cache for the specific prompt context is empty, requiring a full prefill phase to process the input. Steady State: The worker pool is fully initialized and active. The talc allocator has previously requested and retained sufficient heap space from the browser via Memory.grow, eliminating the microarchitectural overhead of new OS page allocations and zeroing24. The KV cache is populated with the system prompt and recent conversation history. GPU clocks have transitioned from idle C-states to high-performance P-states, and the system's thermal equilibrium has stabilized. Resetting the environment to a cold state requires a machine restart or the execution of authorized cache-clearing browser profiles. Transitioning from a steady state back to a warm state requires explicitly clearing the logical KV cache and freeing the active context buffers without destroying the underlying worker pool or the WASM instance.

10. Windows, Linux, arm64, Browser, CPU, and GPU Evidence Matrix

TinyRustLM targets a diverse, cross-platform matrix. Performance promotion requires passing a minimum evidence threshold across these distinct environments to ensure global performance regressions do not occur. For native platform baselines (Windows x64, Linux x64, Linux arm64), physical execution is mandatory. Emulation or translation layers (such as Apple's Rosetta 2 or QEMU) introduce severe CPU cycle distortions, obscure true memory footprints, and are strictly prohibited for generating performance evidence. A physical Linux arm64 testbed requires bare-metal execution on single-board computers or server nodes utilizing Ampere Altra or similar Cortex architectures (e.g., Raspberry Pi 5\)43. For browser targets, the evidence matrix includes the stable deployment lanes of Chromium, Firefox, and WebKit. Because critical performance features—such as WASM SIMD, shared memory via Atomics, measureUserAgentSpecificMemory, and WebGPU f16 support—vary drastically across these rendering engines, the environment capture must meticulously record the exact browser version, active experimental flags, and the cross-origin isolation status of the host document46. Missing metrics (such as timestamp-query restrictions on WebKit or the deprecation of legacy memory APIs on Firefox) are acceptable provided they are explicitly labeled as missing in the receipt. An x64 result cannot be mathematically extrapolated to predict arm64 performance, nor can a scalar WASM result accurately predict SIMD or WebGPU acceleration. Each node in the evidence matrix requires independent execution and verification.

11. Instrumentation-Overhead Calibration

The Heisenberg principle of observability dictates that the act of measuring alters the system's behavior. High-resolution timers, User Timing L3 string serialization, PerformanceObserver callbacks, and WebGPU timestamp-query submissions all introduce execution delays and alter the browser's thread scheduling. The diagnostic laboratory must rigidly calibrate this instrumentation overhead. The system performs automated calibration runs against the predefined suite of tiny fixtures. It compares a baseline execution—where instrumentation is completely disabled via compile-time Rust feature flags—against executions with minimal counters, full local JSON tracing, active browser performance observers48, and full WebGPU timestamp generation enabled. If the full local trace introduces a measurement overhead exceeding 2% of the total execution time, strict sampling rules are enforced. Instead of tracing every individual token decode loop, the system samples every [Figure omitted from source export]th token or aggregates the durations into a single in-memory histogram payload to minimize serialization costs. Diagnostics must never materially alter the execution path, induce unnecessary garbage collection pauses, or prevent the browser's JIT compiler from optimizing the hot inference loops.

12. Privacy-Safe Diagnostics, Support Bundle, and Secret Scan

Telemetry cannot be blindly transmitted to external servers. The laboratory produces a local, user-controlled diagnostic bundle designed to assist developers in debugging and performance tuning without violating the zero-knowledge constraint. Full, unredacted performance traces remain strictly in local memory or OPFS for the user's private inspection. The exportable support bundle contains a bounded summary utilizing explicitly allowlisted fields. It includes coarse hardware classifications (e.g., "8-core arm64, 16GB RAM class") rather than stable, unique hardware fingerprints that could be used for cross-site tracking46. Before any export is permitted, the bundle undergoes deterministic redaction. Secret scanning algorithms analyze the entire payload to prevent the inadvertent leakage of credentials, API keys, or sensitive user data. The scanner employs regular expressions (Regex) to detect known structural patterns (e.g., AWS access keys, OAuth tokens)3. Furthermore, it utilizes Shannon entropy filters to detect high-complexity strings indicative of cryptographic keys or randomized passwords (e.g., Base64 strings exhibiting an entropy [Figure omitted from source export], or hexadecimal strings [Figure omitted from source export])3. Any data failing the secret scan is deterministically replaced with \[REDACTED\_ENTROPY\] or \[REDACTED\_PATTERN\]. Prompts, raw output text, and private absolute filesystem paths are structurally prohibited from entering the bundle schema. If the aggregation of performance statistics or error counts across multiple users is ever authorized by organizational policy, it must utilize Differential Privacy frameworks, specifically the Laplace mechanism. By adding random noise drawn from a Laplace distribution calibrated to the global sensitivity of the counting query, the system mathematically guarantees [Figure omitted from source export]\-differential privacy. The formula applied to the released aggregate is [Figure omitted from source export], where [Figure omitted from source export] is the global sensitivity and [Figure omitted from source export] is the privacy budget50. This obscures the presence or absence of any single user's crash report, ensuring that individual telemetry cannot be reverse-engineered from the aggregate data50.

13. Quality Coupling, Dashboards, Blockers, and Stop Rules

Performance and correctness are inextricably linked; they cannot be evaluated in isolation. A faster matrix multiplication kernel that introduces floating-point drift or degrades the semantic quality of the generation is a severe system regression. Therefore, every comparative performance run must undergo strict quality coupling. The benchmark pipeline verifies that the raw output text or the private cryptographic hash of the output sequence remains perfectly invariant. Different numerical tiers (e.g., scalar f32 vs SIMD vs WebGPU f16) are granted strict, pre-defined regression budgets for acceptable floating-point divergence. If the semantic gate fails, or if the token sequence diverges beyond the authorized budget, the performance run is immediately blocked and marked as a failure. During test execution, a local diagnostic dashboard reports the current operation, elapsed time, active backend, and progress. Throughput is only displayed while the mathematical invariants remain valid. Strict stop rules govern the laboratory environment to prevent the collection of corrupted data. The run is immediately terminated and rejected if:

1. Thermal Drift: The CPU or GPU temperature exceeds a defined threshold, inducing dynamic frequency scaling that invalidates the latency measurements.

2. Memory Leak: The talc allocator counters indicate unbounded heap growth across repeated steady-state turns, indicating a failure to free context buffers28.

3. Output Mismatch: The numerical regression budget is violated, indicating mathematical corruption in the compute shaders or WASM backend.

4. Secret-Scan Failure: The pre-export validation detects high-entropy strings or prompt data attempting to enter the public receipt struct.

5. Instrumentation Corruption: Monotonic clock continuity fails (e.g., timestamp\_mono regresses or jumps unexpectedly), indicating a failure in the browser's high-resolution timer.

14. TDD Backlog and Clean Logging Replacement

The implementation of this diagnostic laboratory follows a strict Test-Driven Development (TDD) backlog, prioritizing privacy boundaries and schema integrity long before performance measurement is attempted.

All legacy telemetry paths and implicit logging frameworks must be systematically deleted. The system must rely entirely on the versioned, privacy-safe event schema to generate observability data.

15. Unknowns Requiring Private Code, Models, and Physical Hardware

While this report defines the exhaustive architectural standard for the diagnostic laboratory, several variables remain unknown and require access to the proprietary TinyRustLM implementation, private models, and physical testbeds to resolve:

1. Exact Tensor Memory Layout: The specific quantization formats (e.g., 4-bit block-wise quantization) and memory alignment requirements dictate the actual internal fragmentation within the talc allocator's chunks.

2. WebGPU Shader Occupancy: The theoretical throughput of the WGSL compute shaders is unknown without profiling the specific register pressure and workgroup sizes on physical hardware, such as Apple Silicon (M-series) or NVIDIA Lovelace architectures53.

3. OPFS Contention Reality: The degree to which concurrent browser processes induce SSD contention (FROST side-channels) during cold model loads cannot be modeled mathematically without physical testing on the target hardware's NVMe controllers54.

4. Specific Prompt Geometry: The exact distribution of prompt lengths, system context boundaries, and multi-turn repetition requires internal fixture analysis to accurately tune the prefill-to-decode statistical weightings for the macro-benchmark suite.

16. Annotated Primary-Source Bibliography

The architectural decisions, statistical methodologies, and privacy mechanisms detailed in this report are synthesized from the following primary standards, academic publications, and engineering documentation:

1. Performance Timeline & User Timing Level 3: W3C Drafts defining performance.mark(), performance.measure(), and high-resolution time origins. Guides the integration of browser-safe latency tracking while mitigating side-channel risks. Retrieved 2026\.17.

2. WebGPU Specification & Timestamp Queries: W3C working drafts governing the WebGPU API, specifically outlining the timestamp-query feature and the strict security mitigations (quantization, disablement) browsers implement against timing side-channels and rowhammer attacks. Retrieved 2026\.10.

3. MeasureUserAgentSpecificMemory: WICG draft specification for extracting isolated JavaScript and DOM memory usage, requiring COOP/COEP headers to mitigate cross-origin information leaks. Details the breakdown, attribution, and bytes properties. Retrieved 2026\.11.

4. Scientific Benchmarking of Parallel Computing Systems: Hoefler, T., and Belli, R. (2015, IEEE/ACM SC15). Establishes the 12 rules for statistical protocols in HPC performance reporting, mandating nonparametric statistics, harmonic means for rates, confidence intervals, and the strict avoidance of single-run claims.1.

5. Criterion.rs Methodology: The statistical foundation for Rust micro-benchmarking, utilizing warmup phases, non-parametric bootstrap resampling, and Tukey's method for outlier classification. Retrieved 2026\.39.

6. Linux Powercap Framework & Intel RAPL: Kernel documentation defining the sysfs interface (/sys/class/powercap/intel-rapl) for reading microjoule-level hardware energy counters (energy\_uj) on Intel architectures, separating package, core, and uncore domains. Retrieved 2026\.5.

7. Linux perf\_event\_open API: System call documentation for accessing hardware performance counters (e.g., CPU cycles), detailing the multiplexing scale factors (time\_enabled / time\_running) required when physical counters are oversubscribed. Retrieved 2026\.35.

8. Talc Allocator: Documentation for the fast, flexible memory allocator optimized for WebAssembly, detailing its dlmalloc-style heap expansion mechanisms, boundary tagging, and counters feature for tracking fragmentation and allocated bytes. Retrieved 2026\.25.

9. FROST (Fingerprinting Remotely using OPFS-based SSD Timing): Security research (DIMVA '26) demonstrating SSD contention side-channels via the browser's Origin Private File System, highlighting the risks of high-resolution timing attacks during large file I/O operations.54.

10. Secret Scanning and Differential Privacy: OWASP and security industry standards for identifying credentials using Regex and Shannon entropy filters3. Formal definitions of the Laplace mechanism for injecting noise into bounded statistical counts to preserve [Figure omitted from source export]\-differential privacy, obscuring individual records in aggregate datasets.50.

Works cited

1. Scientific Benchmarking of Parallel Computing Systems \- Torsten Hoefler, https://htor.inf.ethz.ch/publications/img/hoefler-scientific-benchmarking.pdf

2. Scientific Benchmarking of Parallel Computing Systems \- Semantic Scholar, https://pdfs.semanticscholar.org/0caf/691dc2f25a3eee80b3ac0e2aa72f953e18bc.pdf

3. How Secret Detection Tools Spot Leaks \- Soteri, https://soteri.io/blog/how-secret-detection-tools-spot-leaks

4. OWASP Secrets Management Cheat Sheet: What You Need to Know \- Infisical, https://infisical.com/blog/owasp-secrets-management-cheat-sheet

5. Power Capping Framework \- The Linux Kernel documentation, https://docs.kernel.org/power/powercap/powercap.html

6. Red Alert for Power Leakage: Exploiting Intel RAPL-Induced Side Channels, https://zhenkai-zhang.github.io/papers/rapl.pdf

7. Scientific Benchmarking of Parallel Computing Systems \- Torsten Hoefler, https://htor.inf.ethz.ch/publications/img/hoefler-scientific-benchmarking\_aachen.pdf

8. The browser feature that turns SSD timing into a tracking signal, https://webiano.digital/the-browser-feature-that-turns-ssd-timing-into-a-tracking-signal/

9. Agrégateur de flux | Services de TI \- McGill University, https://www.mcgill.ca/it/fr/aggregator?page=80

10. WebGPU \- W3C, https://www.w3.org/TR/2021/WD-webgpu-20210706/

11. WICG/performance-measure-memory: performance.measureMemory API \- GitHub, https://github.com/WICG/performance-measure-memory

12. perf\_hooks 性能钩子| Node.js v26 文档, https://nodejs.cn/api/perf\_hooks.html

13. WebGPU \- W3C, https://www.w3.org/TR/2021/WD-webgpu-20210518/

14. Features in wgpu \- Rust, https://wgpu.rs/doc/wgpu/struct.Features.html

15. WebGPU \- W3C, https://www.w3.org/TR/webgpu/

16. Only 32 timestamp queries allowed on Metal MacOS? · Issue \#5261, https://github.com/gpuweb/gpuweb/issues/5261

17. User Timing L3 \- Chrome Platform Status, https://www.chromestatus.com/feature/5149401886490624

18. Performance measurement APIs | Node.js v26.5.1 Documentation, https://nodejs.org/api/perf\_hooks.html

19. Long Animation Frames API \- W3C, https://www.w3.org/TR/long-animation-frames/

20. Long Animation Frames API \- Web 関連仕様 日本語訳, https://triple-underscore.github.io/long-animation-frames-ja.html

21. Measure Memory API \- GitHub Pages, https://wicg.github.io/performance-measure-memory/

22. performance-measure-memory/index.src.html at main \- GitHub, https://github.com/WICG/performance-measure-memory/blob/main/index.src.html

23. JavaScript performance beyond bundle size | Read the Tea Leaves \- Nolan Lawson, https://nolanlawson.com/2021/02/23/javascript-performance-beyond-bundle-size/

24. Allocation Benchmarks \- WASM Benchmarks, https://bench.nickb.dev/allocation

25. talc \- crates.io: Rust Package Registry, https://crates.io/crates/talc/4.1.1

26. talc \- crates.io: Rust Package Registry, https://crates.io/crates/talc/4.4.1

27. talc \- Rust \- Docs.rs, https://docs.rs/talc

28. SFBdragon/talc: A fast and flexible allocator for no\_std and WebAssembly \- GitHub, https://github.com/SFBdragon/talc

29. Talc – A fast and flexible allocator for no\_std and WebAssembly | Hacker News, https://news.ycombinator.com/item?id=39545574

30. Virtual vs Physical vs Resident \- Linux Kernel Internals, https://kernel-internals.org/mm/virtual-physical-resident/

31. GetProcessMemoryInfo function (psapi.h) \- Win32 apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-getprocessmemoryinfo

32. PROCESS\_MEMORY\_COUNTE, https://learn.microsoft.com/en-us/windows/win32/api/psapi/ns-psapi-process\_memory\_counters\_ex

33. RAPL zone hierarchy · Issue \#3 · powercap/powercap \- GitHub, https://github.com/powercap/powercap/issues/3

34. Power Capping and RAPL \- Linux Kernel Internals, https://kernel-internals.org/power/power-capping/

35. Writing a Type-Safe Linux Perf Interface in Zig \- pyk, https://pyk.sh/blog/2025-12-11-type-safe-linux-perf-event-open-in-zig

36. perf Events \- Linux Kernel Internals, https://kernel-internals.org/tracing/perf-events/

37. Enhancing PAPI with Low-Overhead rdpmc Reads, https://web.eece.maine.edu/\~vweaver/projects/papi-rdpmc/2017\_espt\_draft.pdf

38. PerformanceAnalysisAndTuning, https://www.scribd.com/document/812432827/PerformanceAnalysisAndTuningOnModernCPUs-SecondEdition

39. Criterion in criterion \- Rust \- Docs.rs, https://docs.rs/criterion/latest/criterion/struct.Criterion.html

40. Analysis Process \- Criterion.rs Documentation, https://bheisler.github.io/criterion.rs/book/analysis.html

41. Benchmarking Data Science: 12 Ways to Lie With Statistics and Performance on Parallel Computers, https://www.computer.org/csdl/magazine/co/2022/08/09847318/1FvJtK2Eisg

42. Benchmarking Rust code using Criterion.rs \- Engineering at DEPT, https://engineering.deptagency.com/benchmarking-rust-code-using-criterion-rs

43. Raspberry Pi 5; ARM Cortex A76 Quad Core Processor; 4GB LPDDR4X RAM \- Micro Center, https://www.microcenter.com/product/673712/raspberry-pi-5

44. Raspberry Pi 5; ARM Cortex A76 Quad Core Processor; 8GB LPDDR4X RAM \- Micro Center, https://www.microcenter.com/product/673711/raspberry-pi-5?ob=1\&storeid=025\&bvstate=pg:5/ct:r

45. Raspberry Pi 5 \- 1GB; ARM Cortex A76 Quad Core Processor \- Micro Center, https://www.microcenter.com/product/704295/raspberry-pi-5-1gb

46. WebGPU Fingerprinting: The Next GPU ID After WebGL, https://browserinsight.net/blog/webgpu-fingerprinting

47. ep136 Monthly Platform 202311 | mozaic.fm, https://mozaic.fm/episodes/136/monthly-platform-202311.html

48. Performance Timeline \- W3C, https://www.w3.org/TR/performance-timeline/

49. \[PDF\] FROST: Fingerprinting Remotely using OPFS-based SSD, https://www.semanticscholar.org/paper/FROST%3A-Fingerprinting-Remotely-using-OPFS-based-SSD-Weissteiner-Weiser/b44f8e14833333c9a4804bd99f8b5e33d10eaf92

50. Learn Laplace Mechanism | Differential Privacy Mechanisms \- Codefinity, https://codefinity.com/courses/v2/321c932f-304b-47a2-a1ee-f5efcc93dd49/c793ce6b-6c39-4e58-8d9c-2d1a88e6a584/d886971c-d628-47e6-b6ad-1ffa61ca1d75

51. Differential Privacy | IEEE Technology Navigator, https://technav.ieee.org/topic/differential-privacy/

52. Lecture 2: Differential Privacy & First Building Blocks \- Inria, https://researchers.lille.inria.fr/abellet/teaching/ppml\_lectures/lec2.pdf

53. What Browsers Do in the Shaders: A Measurement Study of WebGPU Privacy \- arXiv, https://arxiv.org/pdf/2606.26412

54. lcanello — lcanello, https://lcanello.pages.fbk.eu/

55. New FROST attack leverages SSD side-channel to reveal browsing activity \- CyberInsider, https://cyberinsider.com/new-frost-attack-leverages-ssd-side-channel-to-reveal-browsing-activity/

56. Websites can spy on user activity by analyzing SSD behavior \- Help Net Security, https://www.helpnetsecurity.com/2026/05/29/website-tracking-ssd-activity-research/

57. perf\_event\_open(2) \- Arch manual pages, https://man.archlinux.org/man/perf\_event\_open.2.en

58. The FROST attack: how SSD access delays expose users' activity \- Kaspersky, https://www.kaspersky.com/blog/frost-fingerprinting-attack/55970/

59. What is Secret Scanning? Working & Best Practices \- SentinelOne, https://www.sentinelone.com/cybersecurity-101/cloud-security/secret-scanning/