Building PATANYX

I wanted a privacy browser whose core protections did not depend on extensions. Extensions can be useful, but they can also introduce additional code, permissions, and third parties to trust. I chose to build those protections into the browser so I could review and maintain them directly.

PATANYX is a Rust-based, desktop browser for Windows and Linux, made by EdgeXene, a founder-led software and technology company based in Hammond, Indiana. The company develops privacy-focused and business software. EdgeXene also provides implementation, custom application development, research, and related technology services.

PATANYX's slogan is "Leave less behind." The protections live in the browser rather than in add-ons: an ad and tracker blocker, a network freeze and privacy ledger, an encrypted vault and session store, page integrity checks, signed updates and blocklists, a Private Tunnel client, and on-device OCR, which reads text out of images without sending them anywhere.

PATANYX sends me no browsing history, no search terms, no usage analytics and no crash reports. One caveat, in the words of the About page: "on Windows, Microsoft's WebView2 engine reports a minimum of component health data that no application is allowed to switch off." Fingerprint Divergence, on by default and free permanently, adds noise to browser fingerprinting, the practice of recognizing a browser from the details it exposes to websites. It does not make anyone invisible.

Two things sit around the browser. PATANYX Premium is one payment for a fixed term, with no account, and nothing renews; its features are already in the public build and unlock with a license. PATANYX Search, at patanyx.com, is free and funded by partnerships. Everything else is on the PATANYX website, patanyx.net.

I chose Rust for its safety and its speed. Rust's compiler rules out whole classes of memory bugs before the code ever runs, and it compiles to fast native code without a garbage collector.

"Rust-based" means that the browser's application logic and its privacy and security policy are implemented in Rust. The protections listed above are written in Rust, and so are the permission policy and the license checks. Pages are rendered by the engine the platform already maintains, WebView2 on Windows and WebKitGTK on Linux, and PATANYX bundles no copy of Chromium.

That is deliberate. A rendering engine is one of the biggest and most security-sensitive parts of a browser, and a small team maintaining one would not make PATANYX safer; it would add an enormous attack surface to patch. PATANYX puts its effort into what it can own: privacy, security, storage, networking, permissions and the application's behavior around the page. Engine security updates keep arriving through the platform's normal update mechanism, and the application stays compact.

Relying on the platform's engine makes the engine's version matter, so PATANYX has an engine floor: on Linux, a release build refuses to start below a minimum engine version. The browser's own interface is hand-written HTML, CSS and JavaScript in a privileged webview, with no framework, no npm packages and no bundler, and its content security policy forbids inline script outright. Websites load in a separate webview. The Rust toolchain itself is pinned, so every build uses the same compiler.

A privacy browser asks people to trust it. I did not want that trust to rest on my word, so I made three decisions that let anyone check for themselves, and that make the project auditable.

The first was to open the source. The browser is published at github.com/EdgeXene/patanyx under the Apache-2.0 license, so anyone can read, audit and build the code that protects them. The source policy draws the line: "Browser-side privacy and security mechanisms are open source and auditable; commercial backend services and deployment infrastructure are proprietary."

The second was Authenticode signing through Microsoft Azure. The Windows executable carries a verified code signature, so Windows shows my name as the publisher in the file's properties, and anyone can see who made the file before they run it.

The third was Sigstore. Every release binary carries a Sigstore signature, tied to a verified identity instead of a long-lived key and recorded in Sigstore's public transparency log, which makes each signature auditable after the fact. Anyone can verify a download with the command in the repository's README before running it.

Much of my career has been operational strategy and project management, which is why I run Claude as my project manager.

My part in PATANYX is to plan it, decide what ships and review what comes back. I research the options, define what I want built and how it should behave, and give Claude a detailed brief. Claude plans the implementation, does most of the work, and brings in other models when they add something: more capacity, a fresh review, or a challenge to a conclusion. Kimi, Codex, Qwen and DeepSeek draft and review; they do not talk to one another, and everything they produce comes back to Claude to be checked against the real code.

Model	Role in the workflow
Claude	Project management, primary implementation, direct investigation of running systems, verification, integration, and release. I'm part of Claude's Cyber Verification Program, so Claude also runs security audits and penetration tests on my own software.
Qwen	Large drafts across multiple files and assignments that benefit from a broad view of the repository, plus security audits when needed.
Kimi	Bounded drafts where precise behavior matters, plus inventories and structured comparisons.
DeepSeek	Security audits when needed, including a separate assessment produced without seeing another reviewer's findings.
Codex	Independent review, assessment of conflicting reports, final review of security-sensitive changes before integration, and security findings through Codex Daybreak Blue.

Codex, Qwen and DeepSeek can be given permission to write in named scratch copies of the project, so a reviewer can propose a fix while the code is still in context. Kimi works through its API and is never given access to the project's files. Of the models, only Claude may publish, and only what I have approved. The full workflow is in my article My Development Workflow.

Everything arrives signed

A browser keeps receiving things after it is installed: updates, blocklist refreshes and engine advisories. Each of them arrives signed. Update and blocklist manifests are signed with Ed25519 and verified against keys compiled into the binary, and an update does not install unless you give it permission to do so.

The blocklist holds more than 770,000 entries from five sources and refreshes through a signed hourly channel. A host that is also among the most popular sites on the web needs a human decision before it can be blocked.

I'm grateful to CERT Polska / NASK for granting me written permission to use their warning list as PATANYX's fifth source. Established in 1996, CERT Polska operates within NASK, Poland's National Research Institute, and serves as one of the country's three national cybersecurity incident response teams. Its warning list helps major Polish telecommunications providers protect users against phishing and fraudulent websites, a track record I'm glad to draw on for PATANYX.

The data comes from CERT Polska and reaches installed browsers only through PATANYX's signed refresh mechanism. It is not distributed through the repository or included in the browser's built-in list.

Two zero-days in September

In early September, attackers were exploiting CVE-2026-85046, a type-confusion flaw in V8, the JavaScript engine used by Chrome and other Chromium-based browsers. Type confusion means the engine can be tricked into treating one kind of data as another, potentially allowing malicious code to run. On September 5, my first question was straightforward: did it affect PATANYX?

On Linux, this particular flaw did not: PATANYX uses WebKitGTK, which runs a different JavaScript engine. On Windows, installations running an affected version of Microsoft's Chromium-based WebView2 runtime were exposed.

That is one tradeoff of relying on an externally maintained engine: I cannot patch WebView2 through PATANYX itself. Microsoft had released an Edge fix on September 2, but an available fix does not mean every installed WebView2 runtime has received it.

I implemented PATANYX's response that day. The browser records the minimum WebView2 version containing the fix and displays a warning banner when the running engine falls below it. The About panel also shows the exact engine version, so users can check it themselves.

I deliberately kept the browser able to start, so users can see the warning and understand the problem. That warning does not fix the vulnerability; the runtime still needs to be updated.

The minimum version also travels in PATANYX's signed update manifest, allowing me to raise it on installed browsers without requiring a new PATANYX release. The browser accepts increases to that minimum, never decreases.

A second actively exploited V8 vulnerability, CVE-2026-87491, prompted another step. On September 11, I introduced a separately signed engine advisory channel with a deliberately narrow purpose: raising the minimum engine version. It cannot direct the browser to a download or prevent it from starting. As of September 23, the minimum reflects the version containing the fix for that second vulnerability.

Codex reviewed the advisory channel before Claude landed the implementation. On September 23, PATANYX also achieved the OpenSSF Best Practices badge at the passing level. In the badge submission, I cited the September 5 response as an example of how quickly I investigate vulnerabilities and put the measures within my control into place.

Checking what the reviewers find

Before the stable release, I asked DeepSeek and Qwen to look for ways to break PATANYX independently, without seeing each other's findings. The browser's own interface runs at an internal address that websites are not allowed to access. DeepSeek found that adding a trailing period to that address bypassed the access check and classified the issue as critical. Qwen independently found the same gap and rated it less severe.

I then had Claude verify both reports against the actual code. It reproduced the bypass and assessed the issue as serious, though not critical. The check read the address in two different ways, and the trailing period fooled both; a single fix addressed both. To check that the new regression test could detect the problem, the bug was temporarily reintroduced and the test was confirmed to fail. That gave me evidence that the test would catch this particular bypass if it returned.

What I say has to match what you download

Every public claim I make about PATANYX, from the privacy policy to this article, has to match the version people can actually download. I learned that from a close call: a draft privacy policy described two protections I had implemented in the code but had not yet shipped. Checking the downloadable build caught the mismatch before the policy took effect. Finished in development does not mean available to users.

Knowing what changed, by whom, and why

My compliance background shapes how I manage development: I want a clear record of what changed, who contributed, and why each decision was made. With multiple AI models involved, that record matters. My workflow supports it through three checkpoints.

Before each commit, an automated audit checks for credentials and user databases and blocks the commit if it detects them. Changes to the privacy policy, About page, or other public claims about PATANYX also receive a compliance audit before release: a read-only review against my standing rules.

Finally, every working session produces an audit card recording which AI models took part, what reviewers found, how each finding was addressed, and which tests ran. That gives me a record I can return to when I need to understand a decision or investigate a problem.

Keeping experiments out of a release

I keep work in progress separate from changes approved for release. Once I decide a change is ready to ship, it is built and tested before being promoted to a dedicated release branch. That controlled promotion is the only permitted way to update the branch. If it changes through any other route, publishing stops.

Everything I publish to GitHub comes from that branch, including releases and the interim source snapshots I share between them. Those snapshots keep the public code available without waiting for the next packaged version and support the OpenSSF Best Practices criteria. Before publication, each snapshot is automatically checked for never-public material a machine can recognize, then held until I approve that exact snapshot.

Any claim about PATANYX -- whether it comes from a reviewer, Claude, or me -- has to stand up to scrutiny against the source code or the build people actually download. Readers can apply the same standard: the README provides a command to verify each release binary, and SECURITY.md sets out my commitment to acknowledge security reports within five business days.

I also made a deliberate choice not to support traditional browser extensions for now. Extensions are incredibly useful, but they can introduce additional third-party code with extensive access to browser activity and data. My priority is to build more functionality in-house, where I can review and maintain it directly. If extension support comes later, I intend to be selective about which extensions are allowed and how they are vetted.

That is the browser I set out to build: one whose core protections are built in, open for anyone to inspect, and available without installing extra extensions.