Architectural Blueprint for Zero-Trust Local File Ingestion and Ephemeral Research Workflows

Full report

On this page

Executive Summary and Contextual Architecture

The integration of local file ingestion within the active workstation of the Al.Qaeda.net Archival Reconstruction demands a rigorous departure from contemporary web application paradigms. Standard modern workflows rely on transmitting user data to a remote server for validation, indexing, format conversion, and storage. However, the strict privacy and security boundaries of this archival environment dictate that personal research files must never leave the user's local machine. The architecture must enforce a zero-trust, client-side execution boundary that aligns with the data minimization and purpose limitation principles defined in NIST SP 800-53 PT-2 and PT-31. Every operation—from reading and searching to comparing and extracting quotations—must occur entirely within the browser's volatile memory and sandboxed storage limits. Treating the browser as the total perimeter requires the system to assume that all ingested local files are inherently hostile. The application cannot rely on server-side malware sanitization, firewall egress filtering, or robust backend format parsers. Instead, the local workstation must utilize air-gapped, defense-in-depth strategies natively supported by the web platform. The user interface must reflect this closed-loop security model by adopting the deterministic, localized terminology of classic desktop software. Actions must be labeled "File → Open" or "Import Workspace," strictly avoiding cloud-centric terminology like "Upload" or drag-and-drop "Dropzones" that imply network transmission. This report outlines the comprehensive architectural requirements, threat models, and interface specifications necessary to safely ingest, isolate, and interact with temporary local files. By synthesizing advanced browser isolation techniques—including Content Security Policy (CSP) Level 3, W3C Trusted Types, Web Worker memory transfers, and strict origin-private storage eviction—the system can provide seamless research utility without compromising the immutable server-provided archive or the researcher's absolute data privacy.

Foundational Privacy and Content Isolation Boundary

To achieve absolute privacy, the mechanism utilized to access local files is of paramount importance. The analysis indicates that the implementation must rely exclusively on the W3C File API using standard \<input type="file"\> elements, rather than the newer File System Access API. The File System Access API (e.g., showOpenFilePicker()) introduces persistent directory access and read/write capabilities that bridge the gap between the web application and the host operating system2. However, this API has been heavily criticized within security research as a potential tracking vector and an escalation path for advanced malware4. Granting a web application persistent access to a local directory creates an ongoing forensic footprint and contradicts the requirement that imported material must live only in the active working browser context. By contrast, the W3C File API provides a strict, point-in-time snapshot of the selected file6. When a user opens a file via a classic dialog, the browser grants the application read-only access to a Blob representing the file's bytes at that exact moment. The application cannot modify the original file on the user's hard drive, nor can it read subsequent modifications without the user explicitly opening the file again. This enforces a mathematically provable boundary: the data exists solely within the Javascript execution environment's heap memory and is subjected to automatic garbage collection the moment the reference is dropped or the session concludes6.

Security and Threat Analysis

Because the application cannot offload file sanitization to a hardened server, it must implement multiple layers of defense within the client side. The primary security mandate is that opening a user file must never result in the execution of code contained within that file. The browser's same-origin policy is insufficient if an attacker can manipulate the application's JavaScript runtime or Document Object Model (DOM) to execute arbitrary payloads.

Threat Vectors and Vulnerability Classes

Four dominant threat vectors apply to local file ingestion within a browser sandbox: code injection, resource exhaustion, prototype pollution, and parser exploitation. Code injection primarily manifests as DOM-based Cross-Site Scripting (XSS). If a user opens a local file containing malicious HTML, JavaScript, or specifically crafted Markdown, and the application renders that content into the workstation interface without proper sanitization, the script will execute within the trusted context of the application. This execution could allow the script to access the user's active session data, exfiltrate derived notes, or manipulate the interface of the server-provided archive. Resource exhaustion attacks target the browser's memory allocation and synchronous processing threads to cause denial of service. The most common vector is a decompression bomb (or zip bomb), which exploits recursive compression to create a deceptively small file (e.g., a few kilobytes) that expands to gigabytes or petabytes of data8. When a user attempts to import a corrupted or malicious workspace archive, the browser tab will exhaust available RAM and crash, resulting in the loss of all unsaved research notes. Similar exhaustion can occur with highly nested JSON payloads that cause recursive parsing functions to exceed the maximum call stack size10. Prototype pollution is a severe JavaScript-specific vulnerability where an attacker injects properties into Object.prototype, affecting all objects globally within the application environment11. When parsing local JSON files or workspace packages, an unvalidated JSON.parse() operation that feeds into a recursive merge function could introduce a \_\_proto\_\_ or constructor key. This allows the payload to overwrite core application logic, potentially bypassing access controls or modifying the behavior of rendering frameworks11. Finally, parser exploitation occurs when malformed input triggers unexpected behavior in the libraries used to read complex file formats. Bibliographic formats like BibTeX or RIS, which rely heavily on string tokenization, have historically been vulnerable to command injection or infinite loops when processing unescaped macros or unexpected byte sequences14.

MIME Validation and "Magic Byte" Detection

Relying on file extensions (e.g., .txt) or browser-provided MIME types (e.g., text/plain) is a fundamental security risk. Operating systems frequently misidentify files, and malicious actors routinely spoof extensions to bypass superficial filters. A file labeled workspace.json may actually contain an executable payload or a malformed binary structure designed to trigger buffer overflows in WebAssembly parsers. The application must perform strict client-side "magic byte" (file signature) validation. Before any file is passed to a parser, the application must read the first several kilobytes of the file via the FileReader or Blob.arrayBuffer() API. The system must verify the internal structure of the file against the expected format signature (e.g., checking for the PK\\x03\\x04 header in ZIP files, or validating the presence of valid UTF-8 text structures). If a format mismatch occurs, the application must instantly halt the import process and display a period-authentic error dialog stating that the file is corrupted, malformed, or of an unrecognized type.

Supported Formats and Capability Matrix

The workstation must balance deep research utility with rigid security boundaries. Supporting complex, proprietary, or executable formats introduces unacceptable risks to the client-side environment.

Recommended and Explicitly Unsupported Formats

The architecture limits support to highly structured, inert, or purely plaintext formats. Formats such as TXT, Markdown, CSV, and JSON provide immense analytical value while remaining fundamentally harmless until parsed by the application. Bibliographic formats (BibTeX, RIS) are essential for academic workflows and can be parsed safely using heavily constrained, non-evaluating state machines. Exported workspace packages (ZIP archives containing JSON and Markdown) are necessary for cross-session continuity but require stringent unpacking constraints. Conversely, the architecture explicitly rejects Microsoft Office documents (DOCX, XLSX), Portable Document Format (PDF), and legacy rich-text formats (RTF). While modern DOCX and XLSX files are technically ZIP archives containing XML, parsing them client-side requires massive dependencies that are frequently vulnerable to XML External Entity (XXE) injection, XML Signature Wrapping (XSW) attacks, and recursive entity expansion15. Client-side PDF rendering, though possible via tools like PDF.js, introduces immense attack surfaces related to embedded JavaScript engines and complex font-parsing logic. The system must never execute active HTML, macros, shell scripts, or allow arbitrary plugin execution.

Format-by-Format Capability Matrix

Deep-Dive Content Isolation and Safe Treatment Mechanics

The transition from a raw local file on a user's hard drive to a rendered, searchable element in the workstation requires a sequence of rigorous sanitization and normalization steps. Each format presents unique challenges that must be neutralized without relying on a backend server.

Plaintext and Deterministic Encoding Detection

Plaintext files present immediate challenges regarding character encoding. A malformed text file, or a file saved in a legacy encoding (such as Windows-1252, ISO-8859-1, or Shift JIS), can result in mojibake (garbled text) or trigger catastrophic failures in downstream regular expression parsers17. Because the application cannot rely on server-side charset normalization, it must process raw file bytes using the JavaScript TextDecoder API. The architecture mandates the use of the fatal: true flag during instantiation (new TextDecoder('utf-8', { fatal: true })). When this flag is enabled, the decoder will throw a TypeError if it encounters invalid or non-compliant byte sequences, rather than silently inserting the Unicode replacement character (U+FFFD)19. This deterministic failure allows the application to systematically attempt to decode the file. If UTF-8 parsing fails, the system must gracefully catch the error and present a "File Properties" dialog to the user, allowing them to manually declare the correct legacy encoding before the file is permitted to enter the workstation environment.

Markdown Handling, HTML Sanitization, and Mutation XSS

Supporting Markdown and HTML for reading local research notes is highly desirable but exceedingly dangerous. The application must never use native innerHTML or insertAdjacentHTML to inject local file contents directly into the DOM. Instead, the raw text must be converted to an Abstract Syntax Tree (AST), and the resulting HTML must be rigorously stripped of all active elements, event handlers (onload, onerror), and dangerous attributes (srcdoc, formaction) using DOMPurify21. However, DOMPurify alone is historically susceptible to parser differentials known as Mutation XSS (mXSS). This vulnerability occurs when the sanitizer produces a clean DOM tree, but upon serialization and reinsertion into the live document, the browser's native parser applies different rules. Specifically, namespace confusion between HTML, SVG, and MathML elements can cause supposedly benign text to mutate into an executable script tag22. To completely eradicate this threat, the architecture must implement W3C Trusted Types25. By injecting the require-trusted-types-for 'script' CSP directive, the browser engine is forced to reject any raw string passed to a dangerous DOM sink27. The system must define a strict Trusted Types policy via trustedTypes.createPolicy that mandates all DOM insertions pass through DOMPurify27. This establishes an un-bypassable boundary: even if a developer introduces a logic flaw that attempts to render raw local data, the browser engine itself will halt execution with a TypeError, ensuring that local HTML files remain purely inert documents27.

CSV Ingestion, Streaming, and Re-Export Sanitization

CSV files are critical for datasets, but they pose significant performance and security risks. Because these files can easily exceed available heap memory, they cannot be read entirely into a single string. The system must implement a streaming architecture utilizing Web Workers and highly optimized libraries like PapaParse30. By enabling worker execution and utilizing chunked callbacks, the file is read in specific byte limits (e.g., 1MB chunks), parsed into arrays, and aggregated or indexed without freezing the main browser thread32. For maximum efficiency with massive files, the architecture should leverage ArrayBuffer.prototype.transfer to shift memory ownership of the file buffer directly to the worker thread, avoiding the massive CPU overhead of structured cloning34. The most severe security risk with CSV files involves Formula Injection, categorized under CWE-123636. While the browser workstation itself does not execute spreadsheet formulas, researchers frequently extract data from imported files, annotate it, and export the derived workspace notes as a new local CSV. If the original local file contained malicious payloads—such as \=cmd|' /C calc'\!A0—and the researcher includes that text in their derived notes, the resulting export becomes a weaponized payload when opened in a spreadsheet application37. To neutralize this, the application must sanitize any user-derived or extracted data during the re-export phase. Following OWASP Application Security Verification Standard (ASVS) recommendations, the system must inspect the first character of every field. If the field begins with an equals sign (=), plus (+), minus (-), or the at symbol (@), the exporter must systematically prepend a single quote (') to force the spreadsheet software to evaluate the cell as plain text37. Furthermore, for robust resistance against aggressive parsing rules, the system should wrap all fields in double quotes and escape internal quotes by doubling them40. This guarantees that any data derived from a temporary local file remains inert, regardless of downstream software execution.

JSON Validation and Prototype Pollution Prevention

JSON files are necessary for importing proprietary workspace configurations or raw datasets. The primary threat during ingestion is Prototype Pollution. If an attacker crafts a malicious JSON file containing the keys \_\_proto\_\_ or constructor, a naive JSON.parse() operation that feeds into a deep-merge function will traverse the prototype chain and inject properties globally into Object.prototype10. This can silently alter application behavior, bypass authentication checks, or corrupt rendering logic across the entire session13. To safely parse local JSON files, the architecture implements a multi-gate defensive strategy. First, the file is subjected to strict byte-size and recursive-depth limits to prevent denial-of-service10. Second, the JSON.parse() invocation must utilize a custom reviver function that explicitly drops prototype-polluting keys: \JSON.parse(input, (key, value) \=\> (key \=== '**proto**' | | key \=== 'constructor') ? undefined : value)\[cite: 11\]. Third, any internal configuration dictionaries generated from this data must be instantiated usingObject.create(null)or JavaScriptMap\ objects, which lack a prototype chain entirely and are thus immune to prototype manipulation43. Finally, the resulting object must be validated against a strict, predefined JSON Schema to ensure no unexpected executable properties are introduced.

Bibliographic Parsing and Duplicate Identifiers

Researchers require the ability to open .bib (BibTeX) and .ris files to import temporary references. Historically, parsers for these formats have been vulnerable to command injection when processing unescaped macros14. The system must utilize a pure-JavaScript state machine that reads the file strictly as tokenized text, strictly prohibiting the use of eval() or dynamic function execution. An additional architectural challenge arises with duplicate workspace identifiers. A local BibTeX file or workspace package may contain citation keys or UUIDs that collide identically with those in the immutable server-provided archive. To prevent data corruption or UI rendering failures, the local ingestion logic must deterministically namespace all local identifiers upon import. For example, if a local citation key Smith2020 is detected, the parser must automatically rewrite it in memory as local\_session\_Smith2020. If a workspace package attempts to overwrite a core archive UUID, the system must prompt the user with a dialog to either namespace the local entity or abort the import.

Workspace Packages and Zip Bomb Mitigation

Exported workspace packages are ZIP archives containing JSON metadata, Markdown notes, and CSV datasets. When opening a local ZIP file to restore a previous session, the system must guard against decompression bombs. A malicious archive could contain gigabytes of highly compressed zero-bytes designed to cause a catastrophic out-of-memory exception8. The client-side extraction utility must track the compression ratio in real-time as bytes are decompressed. If the uncompressed output exceeds a predefined safety ratio (e.g., 100:1) or an absolute size limit (e.g., 250 MB), the worker must instantly terminate the extraction process and purge the memory buffer8. Furthermore, the system must strictly refuse to extract nested archives, throwing an error if a .zip, .tar, or .gz file is detected within the primary workspace hierarchy.

User Experience and Period-Authentic Interface Design

The user interface must strictly conform to the visual constraints of a classic, period-authentic desktop application. Modern web tropes such as drag-and-drop "upload zones," cloud synchronization icons, or terminology implying server transmission are prohibited, as they erode user trust in the zero-trust local boundary.

Authentic Menu Structures and Dialogs

When a user initiates a file action, they must navigate a classic menu bar (e.g., "File → Open Local File..."). This action triggers a hidden \<input type="file" multiple="false"\> element, invoking the operating system's native file picker45. The UI must never use the word "Upload." Upon selecting a file, the system must intercept the load sequence and present a classic modal dialog titled "Import Properties". This dialog serves as the preview-before-import mechanism. It must display a sanitized, plaintext preview of the first 2KB of the file (rendered in a monospaced font or hex editor view), allowing the user to visually confirm the file contents. The dialog must explicitly state the detected encoding, calculated file size, and the parsed file type. If the file exceeds optimal performance parameters (e.g., a CSV larger than 50MB), the dialog must display a classic system-alert warning icon (a yellow triangle) with authentic phrasing: "Warning: This file exceeds optimal parameters. Opening it may degrade system performance. Do you wish to proceed?" Only upon the user explicitly clicking an "Open" or "Import" button does the file proceed to the ingestion and parsing pipeline.

Temporary Local File Naming and Provenance Design

To prevent a malicious or confusing local file from spoofing an official archival document, the internal system must enforce strict temporary naming conventions. Regardless of the actual file name on the user's hard drive, the ingested file must be prefixed within the UI (e.g., \[Local\] original\_filename.txt). A core requirement is visually distinguishing imported personal material from the immutable server-provided archive. Any interface element, text snippet, or search result that originates from a local file must be flagged with a prominent provenance label. The UI should utilize distinct typography, color coding, or a continuous watermarked banner indicating "Local File," "Personal Data," or "Opened from This Computer." In the citation manager, references generated from a local .bib file should feature a distinct icon (e.g., a computer terminal or floppy disk) compared to the server's archive icon (e.g., a vault or book). This ensures that researchers maintain perfect situational awareness regarding the origin of the data they are analyzing.

Ephemeral Storage and Temporary File Lifecycle

The hardest boundary defined in the architectural requirements is the absolute prohibition of data transmission to the web server, analytics engines, or third-party synchronization services. The lifecycle of a local file must be strictly ephemeral, residing entirely within volatile memory and localized storage silos that are physically isolated by the browser's security model.

Memory Management and IndexedDB

When the user selects a file, the application should generate a blob URI using URL.createObjectURL(file)6. This URI allows the application to reference the file bytes directly from memory without network hops. However, blob URIs create strong memory references. If left unmanaged, repeatedly opening files will cause severe memory leaks6. The system must maintain a strict registry of active blob URIs and aggressively invoke URL.revokeObjectURL() the moment a local file tab is closed or a temporary workspace is cleared. To enable rapid switching between the server archive and the local file during an active session, client-side indexing is required. The system must rely exclusively on IndexedDB to store the full-text search index generated by libraries like FlexSearch or Lunr.js46. IndexedDB respects the browser's origin isolation and privacy boundaries. Crucially, when the browser is operating in Private Browsing or Incognito mode, IndexedDB storage is severely restricted and securely shredded the moment the session ends, aligning perfectly with the ephemeral mandate48.

Page Reloads, Session Closures, and Clearing Temporary Files

The lifecycle of a temporary local file is inexorably bound to the active browser context. If the user reloads the page (F5) or closes the browser tab, the JavaScript execution context is destroyed. The File object references are lost, and the operating system immediately reclaims the memory. The application cannot, and must not, attempt to automatically reopen the local file upon reload, as this would require violating the privacy boundary by requesting persistent file system paths or retaining excessive data in local storage. To handle abrupt closures, the system should implement a beforeunload event listener that actively purges sensitive IndexedDB indices and revokes Blob URIs before the tab closes51. On application initialization, a cleanup routine must sweep the IndexedDB and purge any orphaned indices from previous, abruptly terminated sessions. The user must also be provided with explicit UI controls to clear temporary files. A "File → Close Local File" or "Edit → Clear Session Memory" action must instantly trigger the garbage collection hooks, purge the associated IndexedDB records, and remove the file from the Explorer view. This guarantees that raw imported material leaves no forensic trace on the local machine once the researcher concludes their work.

Exporting Derived Notes

While the raw local file is ephemeral, a researcher may use the workstation's notepad to extract quotations, compare texts, and synthesize new thoughts. These derived notes are distinct from the imported raw file. If the user explicitly clicks "File → Save Workspace" or "Export Notes," the system compiles these notes, sanitizes them (as detailed in the CSV injection section), and initiates a browser-native download prompt using a newly constructed Blob and URL.createObjectURL(). The UI must clearly distinguish between "Closing the Local File" (which purges it from memory) and "Saving Derived Notes" (which creates a new, sanitized file on the user's hard drive).

System Integration and Workstation Tooling

The ingestion of local files must seamlessly integrate with the existing workstation modules—Search, Compare, Notepad, Citations, and Collections—without breaking the abstraction of the server-provided archive. When a local file is opened, it must appear in the application's hierarchical tree view (the "Explorer"). To maintain visual distinction, it must be nested under a high-level, visually distinct node titled "Local (Temporary)" or "Session Files," physically separated from the "Server Archive" nodes. If the file is a supported text format, its contents are tokenized and added to the in-memory client-side search index. This allows the user to query both the remote archive and their local file simultaneously. Search results must display the provenance label, ensuring the user immediately recognizes which hits originate from their local machine. The "Compare" tool must treat the local file as a standard read-only buffer, displaying it side-by-side with archival documents. The "Notepad" and "Collections" tools can accept drag-and-drop text selections from the local file view, treating the copied strings as user-generated input subject to the workstation's standard DOMPurify sanitization rules.

Modal Accessibility and Focus Management

The classic dialogs used for opening files, displaying properties, and previewing content must adhere to strict accessibility standards, specifically the Web Content Accessibility Guidelines (WCAG) 2.2 AA and WAI-ARIA Authoring Practices53. When a "File Open" or "Properties" modal is invoked, the background application must be rendered completely inert to assistive technologies. This is achieved by applying the aria-modal="true" attribute on the dialog container, paired with role="dialog", aria-labelledby, and aria-describedby attributes55. Furthermore, the application must implement a JavaScript-based focus trap. This ensures that pressing the Tab or Shift+Tab keys cycles only through the actionable elements within the modal (e.g., "Preview", "Encoding Format", "Open", "Cancel")53. Keyboard focus must absolutely not leak to the background page, which would cause severe disorientation for screen reader users. When the user dismisses the dialog via the Escape key or the Cancel button, the keyboard focus must programmatically return to the exact menu item or button that originally invoked the modal, preserving the user's navigational state57.

Browser Constraints and Polyfill Strategies

The architecture relies heavily on HTML5 APIs, Web Workers, IndexedDB, and CSP Level 3\. These technologies are widely supported across modern versions of Chromium (Chrome, Edge), Firefox, and Safari. However, specific features require careful constraint management. For example, IndexedDB quotas vary significantly by browser. While Chrome allows up to 60% of disk space per origin, Firefox restricts persistent storage to 50%, and Safari in Private Browsing mode may severely restrict or entirely disable IndexedDB50. The application must utilize navigator.storage.estimate() to verify available quota before attempting to index massive local files, gracefully degrading to a pure-memory (RAM) search model if IndexedDB is constrained59. Additionally, W3C Trusted Types (trustedTypes.createPolicy) achieved baseline cross-browser support only recently (Firefox 146, Safari 26\)27. For older browser versions that do not natively support Trusted Types, the application must include a lightweight polyfill (the W3C Trusted Types tinyfill). This ensures the codebase executes without throwing initialization errors, seamlessly falling back to standard string sanitization if the deep-engine CSP enforcement is absent26.

Benchmark Against Desktop and Local-First Applications

To ensure the user experience matches the expectations of a professional research environment, the local file ingestion architecture must be benchmarked against leading local-first and desktop applications.

The synthesis of this benchmark reveals that while applications like Logseq and VS Code Web rely on the persistent capabilities of the File System Access API, they trade absolute privacy for convenience. By adopting the ephemeral memory model of TiddlyWiki but enforcing the strict CSP and Web Worker isolation of VS Code, the proposed architecture achieves a superior security posture. It sacrifices persistent local state across sessions (requiring the user to re-open the file upon reload) to guarantee absolute data privacy and zero-trust execution, which is non-negotiable for the archival context.

Standards and Security References

The architectural design is strictly governed by the following standardized specifications and security frameworks. Compliance with these standards is required to maintain the zero-trust boundary.

Implementation Acceptance Criteria

To successfully integrate local file ingestion, the engineering team must satisfy the following deterministic criteria prior to deployment:

1. Network Silence Verification: When a file is opened, read, searched, or closed, the browser's Network tab must record exactly zero outbound requests containing any file metadata, content, or telemetry.

2. Strict CSP Enforcement: The application must successfully load and operate with the HTTP header Content-Security-Policy: require-trusted-types-for 'script';. Any attempt to assign a raw string to innerHTML or eval() must result in a fatal TypeError thrown by the browser engine.

3. DOMPurify Integration: All rendered HTML, Markdown, and parsed text must pass through DOMPurify configured to return TrustedHTML, effectively neutralizing mXSS and namespace confusion vectors.

4. CSV Re-Export Sanitization: Any generated CSV export containing data derived from a local file must systematically prepend a single quote (') to any field beginning with \=, \+, \-, or @, and all fields must be wrapped in double quotes.

5. Memory Lifecycle Verification: Monitoring the browser's heap snapshot must confirm that invoking the "Close File" UI action immediately executes URL.revokeObjectURL(), purges IndexedDB, and releases the ArrayBuffer, returning memory consumption to baseline levels.

6. Accessibility Compliance: The "Open File" and "Properties" modal dialogs must trap keyboard focus, support Escape-key dismissal, and utilize aria-modal="true" to hide the underlying workstation from screen readers during interaction.

7. Format Constraints: The file ingestion module must utilize "magic byte" detection to instantly reject executable binaries, Microsoft Office documents, and PDF files, displaying a classic period-authentic error dialog.

8. Visual Provenance: Every UI element rendering data from a local file must persistently display the "Local File" or "Opened from This Computer" visual indicator, ensuring absolute visual separation from the server-provided archive.

9. Duplicate Identifier Resolution: If a local file introduces a UUID or citation key that collides with the server archive, the system must automatically apply a deterministic namespace prefix (e.g., local\_session\_) to prevent application state corruption.

Works cited

1. NIST 800-53 AI Compliance: Secure Federal AI Without Data Leaks, https://privacyscrubber.com/compliance/nist/

2. The File System Access API: simplifying access to local files, https://developer.chrome.com/docs/capabilities/web-apis/file-system-access

3. The origin private file system | Articles \- web.dev, https://web.dev/articles/origin-private-file-system

4. (PDF) User Profiles: The Achilles' Heel of Web Browsers, https://www.researchgate.net/publication/391120192\_User\_Profiles\_The\_Achilles'\_Heel\_of\_Web\_Browsers

5. Demystifying Progressive Web Application Permission Systems \- arXiv, https://arxiv.org/pdf/2509.13563

6. Blob URLs: Browser Support, Features, Limitations \- TestMu AI, https://www.testmuai.com/learning-hub/blob-url-browser-support/

7. File API \- W3C, https://www.w3.org/TR/FileAPI/

8. What is a Zip Bomb (Decompression Bomb)? \- Mimecast, https://www.mimecast.com/content/what-is-a-zip-bomb/

9. What is Decompression Bomb (Zip Bomb, Zip of Death Attack)?, https://www.geeksforgeeks.org/computer-networks/what-is-decompression-bomb-zip-bomb-zip-of-death-attack/

10. How Do I Safely Parse Untrusted JSON? \- Inventive HQ, https://inventivehq.com/blog/how-do-i-safely-parse-untrusted-json

11. Prototype Pollution — High Severity (CVSS 8.1) | SecureBlock, https://www.secureblock.io/vulnerabilities/prototype-pollution

12. Prototype Confusion: abusing prototypes when prototype pollution is, https://medium.com/@ql1ch/prototype-confusion-abusing-prototypes-when-prototype-pollution-is-not-exploitable-ec3d18aefdb7

13. Invisible JSON Response Tampering via Prototype Pollution Gadget, https://github.com/advisories/GHSA-3w6x-2g7m-8v23

14. Command Injection in bibtex-ruby | CVE-2019-10780 | Snyk, https://security.snyk.io/vuln/SNYK-RUBY-BIBTEXRUBY-542602

15. Cloud security and authentication vulnerabilities in SOAP protocol, https://www.frontiersin.org/journals/computer-science/articles/10.3389/fcomp.2025.1595624/full

16. Known XML Vulnerabilities Are Still a Threat to Popular Parsers and, https://orbilu.uni.lu/handle/10993/21242?\&locale=fr

17. How to Fix Mojibake: Repair Garbled Text Instantly \- The Text Tool, https://thetexttool.com/blog/fix-mojibake-mixed-encodings

18. TextDecoder.prototype.ignoreBOM not working as expected, https://stackoverflow.com/questions/62334608/textdecoder-prototype-ignorebom-not-working-as-expected

19. TextDecoder: encoding property \- Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/encoding

20. Decode Hex to UTF-8 Without Garbled Text — hextoascii.co, https://hextoascii.co/articles/decode-hex-to-utf8-text

21. Security Goals & Threat Model · cure53/DOMPurify Wiki \- GitHub, https://github.com/cure53/DOMPurify/wiki/Security-Goals-&-Threat-Model

22. Mutation XSS (mXSS): Definition & Security Context \- Pentesterlab, https://pentesterlab.com/glossary/mutation-xss

23. Mutation XSS via namespace confusion – DOMPurify \+2.0.17 bypass, https://securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass.html

24. From SVG and back, yet another mutation XSS via ... \- Medium, https://vovohelo.medium.com/from-svg-and-back-yet-another-mutation-xss-via-namespace-confusion-for-dompurify-2-2-2-bypass-5d9ae8b1878f

25. Trusted Types \- W3C, https://www.w3.org/TR/trusted-types/

26. Trusted Types API \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Trusted\_Types\_API

27. Beyond script-src: how CSP Trusted Types locks down DOM XSS, https://www.uriports.com/blog/csp-trusted-types/

28. The CSP require-trusted-types-for Directive \- Content Security Policy, https://content-security-policy.com/require-trusted-types-for/

29. JavaScript Security Best Practices & Vulnerabilities (2026) \- Corgea, https://corgea.com/learn/javascript-security-best-practices

30. Understanding Streaming in PapaParse \- StudyRaid, https://app.studyraid.com/en/read/11463/359350/understanding-streaming-in-papaparse

31. Papa Parse \- Powerful CSV Parser for JavaScript, https://www.papaparse.com/

32. FAQ \- Papa Parse, https://www.papaparse.com/faq

33. Architectural Choices for CSV Processing in JavaScript, https://npm-compare.com/csv,csv-parser,fast-csv,papaparse

34. Heavy Data Processing in JavaScript Part 2 \- Beyond Web Workers, https://www.tugrik.net/blog/heavy-data-processing-in-javascript-part-2-beyond-web-workers

35. \[Pwn2Own 2024\] WebCodecs VideoFrame Race Condition UAF, https://issues.chromium.org/issues/330563095

36. File \- MITRE D3FEND, https://d3fend.mitre.org/ontologies/d3fend.owl

37. CSV Injection \- OWASP Foundation, https://owasp.org/www-community/attacks/CSV\_Injection

38. Formula Injection Protection \- CSV Export \- Telerik.com, https://www.telerik.com/kendo-react-ui/components/grid/export/csv-export/formula-injection

39. Beware of formulas: Comma Separated Victims | SMC Tech Blog, https://techblog.smc.it/en/2021-01-04/beware-of-formula/

40. Preventing CSV Injection \- Information Security Stack Exchange, https://security.stackexchange.com/questions/279321/preventing-csv-injection

41. Best-practice methods to prevent CSV formula injection attacks in, https://www.cyberchief.ai/2024/09/csv-formula-injection-attacks.html

42. How to Build Secure-by-Default Node.js APIs \- freeCodeCamp, https://www.freecodecamp.org/news/how-to-build-secure-by-default-node-js-apis/

43. Map \- JavaScript \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/Map

44. sunzip \- PyPI, https://pypi.org/project/sunzip/

45. Privacy Policy — Delete Metadata | Client-Side Metadata Removal, https://deletemetadata.com/privacy

46. awesome-javascript \- CodeSandbox, https://codesandbox.io/p/github/allnim/awesome-javascript

47. Browser Storage Types and Their Maximum Limits \- DEV Community, https://dev.to/vishwas/browser-storage-types-and-their-maximum-limits-174f

48. Using IndexedDB \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB\_API/Using\_IndexedDB

49. Storage quotas and eviction criteria \- Web APIs \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/Storage\_API/Storage\_quotas\_and\_eviction\_criteria

50. What are IndexedDB's storage limits across different browsers, https://www.mindstick.com/interview/34337/what-are-indexeddb-s-storage-limits-across-different-browsers-platforms

51. Harnessing Frontend Storage: A Comprehensive Guide to Browser, https://utkarshbansal01.medium.com/harnessing-frontend-storage-a-comprehensive-guide-to-browser-based-data-management-eaa7cf29d69f

52. Testing Browser Storage \- WSTG \- v4.2 | OWASP Foundation, https://owasp.org/www-project-web-security-testing-guide/v42/4-Web\_Application\_Security\_Testing/11-Client-side\_Testing/12-Testing\_Browser\_Storage

53. Accessible Modal Dialog \- ARIA, Keyboard & Focus Management, https://www.phoca.cz/a11y-component-lab/modal-dialog

54. Dialog (Modal) Pattern | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

55. ARIA: aria-modal attribute \- MDN Web Docs \- Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-modal

56. Modal \- Carbon Design System, https://v10.carbondesignsystem.com/components/modal/accessibility/

57. Accessible Modal Dialogs & Popups, ARIA | ExceedAbility, https://exceedability.com/modals-popups-and-dialog-boxs.html

58. Accessible Modal Dialog a Guide to WCAG Compliance, https://www.adacompliancepros.com/blog/accessible-modal-dialog

59. The Browser Storage API \+ Cheat Sheet | by Tanvi Dadwal | Medium, https://medium.com/@tanvidadwal799/the-browser-storage-api-cheat-sheet-be6e4afff0c0

60. Baseline 2026: Three CSS and Platform Features Actually Safe to, https://blog.codercops.com/blog/baseline-2026-css-features-production-guide

61. Prevent DOM-based cross-site scripting vulnerabilities with Trusted, https://web.dev/articles/trusted-types