This is the version that shipped with Nightjar Browser 0.3.0. The current one is at /security.html.

Security — Nightjar Browser

Last updated: 2026-09-11 · Applies to: Nightjar Browser 0.3.0

This answers the questions people actually ask about a browser that runs a language model on their own machine, including the ones where the answer is "we don't". It is the counterpart to PRIVACY.md, which covers what is kept and what is sent; this covers what is patched, what is verified, and what to do when something is wrong.

Reporting something

trynightjar@outlook.com. There is no bug bounty and no formal SLA — this is a small project and pretending otherwise would waste your time. What you will get is a reply, and a fix if the finding is real.

If you would rather not send details by email first, send a one-line "I have found something in X" and we can arrange somewhere better.

Please do report publicly if we go quiet. A finding nobody acts on is worth more to users disclosed than sat on, and LICENSE §2a explicitly permits publishing what you find, including when it is unflattering.

Updates

How do I get security updates?

It depends which part, and the split matters more than it sounds:

Component	When a fix reaches you	What you do
Page engine (WebView2 / Chromium)	Whenever Microsoft ships one, in the background	Nothing. Restart if it has been a while
llama.cpp (the model runtime)	When we raise the pinned build and release	Install that release; the runtime then downloads itself
Python dependencies	When we raise the pins and release	Install that release
Nightjar itself	When we release	Install it. The browser tells you there is one

The middle two are worth being precise about, because "pinned" sounds more manual than it is. You never fetch llama.cpp yourself. Once you are running a Nightjar whose pin has moved, the browser notices the installed runtime no longer matches, and downloads the new one — verifying its sha256 before it will run it. What waits for us is the decision to move the pin, not the delivery.

Three different things check three different things, and it is easy to run them together:

The browser, on launch, asks whether there is a newer Nightjar. Only that — not llama.cpp, not the Python packages.
The browser, when loading a model, checks the installed llama.cpp against the pin its own build carries, and fetches it if they differ.
A weekly job on our side reads published advisories for the pinned dependencies and watches llama.cpp releases. That one runs on our infrastructure and tells us. It never touches your machine, and it exists so that "nobody noticed" is not why a pin is out of date.

Chrome and Edge just announced a batch of CVEs. Am I affected?

Almost certainly the fix has already reached you, or will without you doing anything.

Nightjar renders pages with WebView2 in Evergreen mode, which is the same Chromium engine Edge uses, updated through the same Microsoft update service. When Microsoft patches those CVEs, your copy is patched — no Nightjar release involved. This is the single best security property of building on WebView2 rather than bundling a browser engine.

Two things can interrupt it:

A running WebView2 keeps the version it loaded. Restart the browser.
Some machines have Edge Update disabled by policy, usually in managed environments. Then the runtime stays where it is and nothing tells you.

How do I check which engine version I have?

The panel shows it: Page engine: WebView2 <version>, beside Host RAM. Compare it against Microsoft's WebView2 release notes.

If it says version not reported, the runtime is old enough not to expose it, which is itself a reason to update it.

Why is llama.cpp pinned if that stops it getting fixes?

Because the alternative is worse. The pin is a sha256 digest, and it is what makes a substituted binary fail to install rather than run: llama.cpp ships as an executable that this application downloads and then executes, and before 2026-09-04 it was accepted on TLS alone. TLS protects the transport; it says nothing about whether the bytes at the far end are still the ones we meant, which is exactly what a hijacked release produces.

The cost is real and we are not pretending otherwise: an upstream fix arrives only when we bump the pin. A weekly job checks requirements.txt against published advisories and compares the pinned llama.cpp build against the current release, so "nobody noticed" is not the reason a fix is late.

Does Nightjar update itself?

No. It checks — one request to github.com on launch, sending the version you have and nothing else — and tells you if there is a newer build. Installing is yours to do.

You can switch the check off in Settings → Privacy & blocking. It is on by default because nothing here except the page engine patches itself, and an update nobody hears about is a fix nobody installs.

What is verified

What stops a tampered download running?

Model runtimes (llama.cpp, CUDA libraries) are pinned by sha256 and the download is rejected if it does not match.
Archives are extracted with path containment and refuse symlinks, so a crafted archive cannot write outside its destination — which matters especially here, because what gets extracted is then executed.
The WebView2 installer, on the rare machine that needs one, has its Authenticode signature checked and must be signed by Microsoft before it is run.
Models are fetched directly from Hugging Face over HTTPS from an allow-listed host. Where a registry entry carries a digest it is enforced.

Is the local AI server exposed to anything?

It binds 127.0.0.1 only, and requires an API key that is generated fresh on every start and written to a file readable by your account. Nothing listens on an external interface.

Can a web page reach the browser's internals?

No. There is no JavaScript bridge exposed to page content — the assistant panel communicates through its own channel, and a page cannot call into it.

What this does not protect against

Stated plainly, because a security page that only lists strengths is marketing.

Prompt injection. Hidden text is removed from a page where it can be found, which is not the same as being safe from it. LIMITATIONS.md lists what the detection misses.
Fingerprinting. A page can still identify your machine by its fonts, screen and hardware. No browser setting here changes that.
Your network. Your ISP or employer still sees which sites you open. This is not a VPN and cannot become one.
A compromised machine. Everything is stored locally, so local access is full access. That is the trade for having no servers.
Small-model mistakes. A local model will get things wrong that a large hosted one would not. The assistant labels where an answer came from; it cannot make a wrong answer right.

Can I verify the binary matches the source?

Not yet. The source is published so the privacy claims can be read rather than believed, but builds are not reproducible, so nothing proves the installer you downloaded was built from it. If you need that assurance, build from source yourself.

Saying so is better than letting "the source is public" be heard as more than it is.

Known unfixed items

Kept here rather than in a private file, because the list is short and a user deciding whether to trust this deserves it:

Builds are not reproducible — above.
The application is unsigned. Windows will warn you on first run, and it is right to. Code signing is pending the certificate.
Accessibility has not been audited, which is a usability failure before it is a security one but can be both.

Questions, or something that belongs on this page: trynightjar@outlook.com · Purple Comet LLC, California.