I will try to outline the technical model we have in mind as clearly as possible. Your reference to Proxifier serves as an excellent benchmark for the driver's core functionality. Our Desired Technical Model: 1. Driver Core Functionality (WFP Callout Driver) Technology: The driver should be based on the Windows Filtering Platform (WFP). Task: Its primary task is to intercept all outgoing TCP/UDP connection attempts on the system. Application Identification: For each connection attempt, the driver must be able to uniquely identify the originating process, ideally by the full path (or pid) to its .exe file (e.g., C:\Program Files\SomeApp\someapp.exe). Ruleset and Default Behavior (Whitelist Mode): Default Mode: "Default Deny". By default, the driver should allow all network connections from all applications. Whitelist: There will be a dynamic whitelist of applications. Only processes whose full path is on this whitelist are allowed to establish connections. All others will be blocked. 3. Communication Interface (IOCTL Interface): The driver must provide a secure IOCTL interface for a user-mode service. The following operations must be possible through this interface: Add Rule: Add an .exe file (by its path) to the whitelist. Remove Rule: Remove an .exe file from the whitelist. Clear Ruleset: Remove all rules from the whitelist. Query Current Ruleset: Return a list of all currently effective whitelist paths to the user-mode service. 4. User-Mode Service as a Bridge: Component: A dedicated Windows Service (written in C++, C#, or Rust, depending on your expertise) will be the sole component communicating with the driver via the IOCTL interface. API for our UI: This service must expose a local API (REST or WebSocket) on localhost. Our JavaScript/TypeScript application will communicate exclusively with this API to manage the whitelist. Example Flow: Our UI sends an HTTP request to the local service: POST /add-rule with { "path": "C:\\path\\to\\app.exe" }. The service receives the request, validates it, and calls the corresponding IOCTL function on the driver to add the rule. 5. Installation & Management: The driver should be installable as a system service (via an .inf file, as you described for Proxifier) and should be controllable via standard commands like net start YourDriverName and net stop YourDriverName. In summary, we are looking for a solution where your WFP driver acts as the "muscle" in the kernel, and the user-mode service, which you would also develop, acts as the "brain" that receives commands from our UI and relays them to the driver. I hope this detailed description provides the clear picture you need. Please let me know if this information is sufficient for you to create an initial estimate or a proposal.