Major Privacy puts a kernel isolation driver between your apps and everything else

The driver is what makes the rest of the feature list possible

The architecture is stated in the first paragraph of the documentation and it explains the whole product. Major Privacy brings a multitude of new functionality made possible through the use of a custom kernel isolation driver, and conceptually it is a HIPS, a Host Intrusion Prevention System. The driver can monitor and filter file and registry access, and it can protect processes from being manipulated by other processes. That last capability is the unusual one, and it is what separates the project from a firewall with a settings page. Because the enforcement point is in the kernel, the tool can act on processes running with system or administrative privileges, which is exactly the case a user-mode blocker cannot win. The repository layout supports the reading, with a Driver directory, a Framework directory, a Library directory and a Service directory among the top level entries, plus a GoAPI directory that suggests some components are written in Go, and a MajorPrivacy.sln solution file at the root.

Process protection isolates user processes from elevated ones

The feature list leads with process protection, and the mechanism is worth understanding on its own. You can protect user processes in secure enclaves from other processes, including elevated and system processes, and the README states the goal in the strongest terms, that unprivileged user processes can be protected from being compromised and their secrets exfiltrated, even from threads running with system or administrative privileges. The integrity level control is the related mechanism, since it sets the integrity level of processes in a secure enclave to Protected, which isolates user objects, including their windows, from other processes. The stated purpose is to defend the user from legitimate but overreaching software, so that the software can be safely used and the companies behind it cannot access anything the user did not choose to make available. That framing matters, because most security tooling is aimed at malware, and this is aimed at the software you installed on purpose.

Restriction is rule based: programs that may start, DLLs that may load

Two of the older capabilities survive into the current build and they are what the project calls its own rule-based software restriction mechanism, the ability to prevent unauthorized or undesired applications from running. The feature list describes software restriction as blocking undesired processes from starting and undesired DLLs from loading, and the interface has a dedicated Program Rules screen for it. File and folder protection is the same idea applied to data, protecting selected files and folders from being accessed by unauthorized processes, with an Access Rules screen. Registry protection is described as file and folder protection but for registry keys, and the feature list marks it as not enabled in the beta build, which is the kind of detail worth noting before you design a policy around it. Together these three layers let you state, per program, what it may run and what it may read, and the specificity is the point.

Network control leans on Windows mechanisms and adds DNS inspection

The network side is described as leveraging the Windows built-in mechanisms to restrict network traffic, with an advanced network firewall to manage outbound and inbound communication as the user-facing part. The two additions that go beyond a firewall are DNS inspection and DNS filtering. Inspection monitors the DNS cache and traces events to determine which domains are being accessed by running processes, which turns the resolver into a source of attribution rather than just a way to look up addresses. Filtering can filter all DNS requests with a set of pre-defined block lists, described as pi home compatible, and your own custom rules. The pre-defined list is a meaningful detail because it means the default posture is not an empty rule set that you have to build from nothing. Proxy injection, which would force arbitrary processes to use pre-defined network proxies, is in the feature list but is marked as not yet implemented.

Secure volumes are the most ambitious feature and the least finished

The idea here is distinctive and the status line is unambiguous. Major Privacy is capable of creating protected volumes located in encrypted container files, so access to confidential data is only possible when the user provides the correct password and the tool is actively filtering filesystem accesses. The feature list describes secure drives as encrypted volumes stored in disk images fully guarded by file and folder protection to prevent unauthorized access to confidential data, even from kernel mode, but it is marked as not yet implemented. The ImDisk and ImBox directories in the repository suggest the container mechanism borrows from those projects. A separate tweak engine handles the more conventional part of the privacy job, hardening the Windows configuration by disabling undesired telemetry and cloud features, with a Tweaks.ini file at the repository root and a Privacy Tweaks screen in the interface. The screenshots in the repository cover the main interface and each of the rule screens, including secure volumes, which suggests the UI work is further along than the underlying capability.

The privacy agent logs what your applications actually do

The observability feature is the one that changes how you use the tool. The privacy agent logs file, registry and network access, and it provides comprehensive logs and visualizations of process activity on the host system, which the documentation says enables the user to check if their applications are only doing what they want them to do. That is a different proposition from blocking. A tool that blocks gives you a failure when something is denied, while a tool that logs and visualises gives you a picture you can reason about, and the picture can be turned into rules afterwards. It is also where the tool becomes slow to use, because capturing access events at the kernel level and presenting them has a cost, and a system with heavy file activity will produce a lot of it. The MiniDump and HookDll directories in the repository point to the mechanism, a hook library alongside crash dump handling.

Getting the build: a release, a driver, and a licence to match

There is no install command in the repository, and the documentation points to the release page instead, with the latest release linked from the download section. Since the project ships a kernel driver, an installer is part of the delivery rather than something a user assembles, and the Installer directory in the repository tree matches that. The licensing is the part that catches people out, and the documentation addresses it under a licensing heading. The tool is open source, but the license is described as a bit more restrictive than typical open source licenses, and the wording is that MajorPrivacy is free like in freedom but not free like in free beer, which means that if you are using it you are expected to get a license from xanasoft.com, and the user interface will remind you of this from time to time. If you want to publicly distribute self-compiled binaries, the documentation says to review the LICENSE file for details.

Where Major Privacy is the wrong choice

The first wrong case is a machine you do not own or cannot compromise. A kernel driver is a privileged component, and a driver that monitors and filters access across the system is a large surface to trust in something you cannot audit yourself. On a corporate machine, driver signing policy and procurement will decide this before the features do. The second wrong case is a user who wants a permissive licence, since the project is explicit that the licence is more restrictive than typical and that the expectation is to obtain one from the vendor, so a company with a legal review of dependencies will have a conversation to have. The third is anyone expecting a finished product, because the feature list itself marks registry protection as not enabled in the beta build and proxy injection and secure volumes as not yet implemented, and a security tool that quietly does not enforce a rule you configured is worse than one that lacks the rule. The fourth is a user who only wants telemetry off and cloud features disabled, since the tweak engine covers that much smaller job, and a driver-based system is a large amount of machinery for it.

Editorial conclusion

Users who want to contain software that is legitimate but overreaching, and who are willing to install a kernel driver and accept that a driver is a privileged component on their machine, are the people Major Privacy is for, and the secure enclave model is the feature that separates it from a firewall plus a tweak script. It is the wrong tool for a corporate machine where a signed driver from a known vendor is a procurement requirement, for anyone who wants an open source licence, since the project states the licence is more restrictive than typical and expects users to obtain a licence from xanasoft.com, and for a machine where the extra kernel component is more risk than the exposure you are managing. Check three things before you rely on it: that the features you need are actually enabled, since registry protection is not enabled in the beta build and proxy injection and secure volumes are not yet implemented, that you can obtain a licence if you intend to distribute a self-compiled binary, and what the driver does on a machine whose hardware or hypervisor configuration it does not recognise. The last push was on 2026-07-26 and the newest release is v0.100.1 from the same day.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xanasoft/MajorPrivacy on GitHub