Browser Extension Security & Permissions
A 100% transparent audit of what our Chrome & Edge extension accesses and why.
🛡️ Our Zero-Access Privacy Guarantee
The NeXDM browser companion extension operates under a strict Privacy by Design standard. We do NOT collect browsing history, do NOT read input form data or passwords, do NOT inspect cookies, and do NOT transmit analytical telemetry to remote cloud servers. All download routing occurs locally and deterministically on your PC.
1. The Manifest V3 Security Paradigm
In legacy browser extensions built under Google's older Manifest V2 platform, extensions enjoyed broad, unrestricted access to web traffic via blocking webRequest APIs and persistent background pages that ran indefinitely in system memory. This architecture created vulnerabilities where compromised extensions could silently intercept passwords or inject rogue advertising scripts.
NeXDM is built natively under the modern Manifest V3 (MV3) standard enforced by Google Chrome, Microsoft Edge, and Brave. Key architectural safeguards include:
- Ephemeral Service Workers: The extension background script does not sit resident in memory. It terminates when idle and wakes only when a download event is explicitly triggered.
- Zero Remote Hosted Code: All executable JavaScript is packaged statically within the extension archive. MV3 strictly forbids executing dynamically fetched code from external CDNs, guaranteeing that the code inspected during Chrome Web Store review is the exact code executing on your machine.
- Declarative Rule Matching: Rather than granting the extension arbitrary permission to read and modify raw network streams, routing rules are declared statically via
declarativeNetRequest.
2. Inter-Process Communication: The Native Messaging Host Protocol
A frequent question from security researchers is: How does the browser extension communicate with the NeXDM desktop application?
Many download tools cut corners by opening an unauthenticated local HTTP or WebSocket server (such as http://127.0.0.1:9000). This introduces a severe vulnerability known as Cross-Site Port Hijacking: any malicious website you visit in any browser tab could potentially make a background fetch() request to localhost, injecting unauthorized download tasks or reading system information.
🔒 How NeXDM Native Messaging Eliminates Network Vulnerabilities:
Instead of listening on network sockets, NeXDM implements the official operating system Native Messaging Host specification:
- The desktop application registers a unique cryptographic host manifest in the Windows Registry under
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.nexdm.downloader. - The browser launches the native binary as a restricted child process connected via OS pipes: standard input (
stdin) and standard output (stdout). - Each message is framed by a 32-bit integer length prefix followed by UTF-8 encoded JSON. No network ports are opened on your PC. No third-party application or website can intercept or inject messages into this closed OS pipe.
3. Manifest V3 Permission Audit & Technical Rationale
Every permission declared in our manifest.json is strictly audited to conform with the Principle of Least Privilege:
Download Stream Interception
Why It's Needed: Allows the companion extension to detect when a user initiates a file download in Chrome or Edge and seamlessly hand the source URL, HTTP referrers, and user-agent string to the 64-segment NeXDM desktop engine instead of the browser's single-stream downloader.
Security Boundary: Triggered exclusively upon user download actions. Never triggered during regular page navigation.
Host Process IPC Link
Why It's Needed: Establishes the secure OS standard pipe connection to the installed NeXDM desktop application binary on your computer.
Security Boundary: Restricts communication exclusively to the verified local binary matching our registered Windows App ID.
Right-Click Menu Hook
Why It's Needed: Registers the "Download with NeXDM" option inside your browser's right-click contextual menu when hovering over links or downloadable media.
Security Boundary: Only receives target link URLs when right-clicked by the user.
MIME Header Matching Without DOM Sniffing
Why It's Needed: Inspects HTTP response headers (such as Content-Disposition: attachment and file extensions like .iso, .zip, .tar.gz) to trigger the high-speed download overlay without intercepting page bodies.
Security Boundary: Evaluated entirely within Chromium's internal declarative matcher. The extension's JavaScript engine never sees the content of the web page.
4. DeclarativeNetRequest: Why MV3 Protects User Privacy
In older Manifest V2 extensions, developers used the blocking chrome.webRequest.onBeforeRequest API. This gave extensions programmatic access to inspect, delay, modify, and log every single HTTP packet passing through the browser—creating a massive privacy hazard if the developer had malicious intent.
Under Manifest V3, NeXDM utilizes declarativeNetRequest. Instead of intercepting the data inside extension code, NeXDM supplies a static JSON rule-set to the browser engine itself:
- Zero In-Memory Packet Peeking: The browser handles header rule evaluations natively in compiled C++. The extension JavaScript process does not receive or log URLs unless a download action is explicitly matched.
- Protection Against Session Hijacking: Because our rules never read request headers (such as
Authorization: Beareror session cookies), session tokens can never leak across the IPC boundary. - Immunity from Web Page Script Tampering: Malicious scripts on rogue websites cannot tamper with extension internals because content scripts operate in strictly isolated execution worlds.
5. Permissions We Explicitly DO NOT Request
To provide absolute clarity on what NeXDM cannot access, the following intrusive browser permissions are deliberately omitted from our manifest:
Frequently Asked Questions
Have an independent security question or want to report a vulnerability?
Contact NeXDM Security Office (security@nexdm.in)