Trivalent hardens Chromium by making the safe features the default

What the project is, and what it is made of

Trivalent is a security-focused, Chromium-based browser for desktop Linux, inspired by Vanadium, and it is intended for use in secureblue.

The mechanism matters more than the branding. The repository's primary language is recorded as Diff, and the top level makes that obvious: there is a patches directory, a build directory, a copr_script.sh, a selinux directory, a docs directory, and a set of licence files. There is no browser source here. Trivalent takes Chromium, applies a patch set, and builds the result.

The Vanadium patch set is the base. The scope section says the patches in scope are the desktop-relevant patches from Vanadium, located in patches/third_party/vanadium, so the lineage is explicit and the patches are vendored rather than fetched at build time.

The rest of the scope is a hardening brief. Changes that increase hardening against known and unknown vulnerabilities are in scope, and so are changes that make secondary browser features opt-in instead of opt-out, with the password manager and search suggestions given as examples. Changes that disable opt-in metrics and data collection count, as long as they have no security implications, and minor user experience or usability improvements count provided they toggle or augment existing elements, with no overhauls or reworks of existing functionality, and keeping the changes minimal and easily toggleable.

That last clause is a style guide for a security patch set: every hardening change should be something a user can turn back off.

The two lines the project refuses to cross

The out of scope list is short and states the project's values plainly.

Any changes that sacrifice security for privacy are out of scope, with enabling MV2 given as the example, and the reason is linked to the Chrome developer documentation on the extension migration and why it improves security. The other rule is that any novel functionality unrelated to security is out of scope.

Those two lines together are the whole design brief. This is a browser whose differences from stock Chromium are about reducing what the browser can do, not about adding features. The privacy benefit is a side effect of the security posture, which is a stricter and more defensible position than claiming both at once.

The MV2 example is the concrete one. Manifest V2 extensions ran with broad host permissions and are being phased out of Chromium, and the project treats keeping them as a privacy gain that is actually a security loss, because a broad permission extension model is a large attack surface. That is why the browser stays on the modern extension platform even though some users would prefer the old behaviour.

For a user, the practical reading is that a Trivalent user will occasionally find that something they relied on in Chrome is off by default and needs a flag to turn back on.

Installation, and what support means here

The installation section is unusually precise about the difference between supported and permitted.

Official support is only provided via secureblue, and unsupported installation is also possible via the project's own repository at repo.secureblue.dev. The documentation then defines the term: support here refers to which systems Trivalent is tested against, and it does not mean that it is forbidden to open GitHub issues regarding Trivalent's use on other systems.

That is a careful framing and it is worth internalising before filing anything. The project is not gating installation, it is being clear that its testing only covers the distributions secureblue supports. The general Linux packages ecosystem is represented by the copr_script.sh file at the top of the repository, which is a COPR build script.

The build badges show that the project itself builds for two architectures, x86_64 and aarch64, with a separate workflow for each, and the release tags follow the same pattern, with 155.0.8059.84-448025-x86_64 and 155.0.8059.84-448025-aarch64 both from 2026-10-16. The version string carries the Chromium version, the Chromium build number and the architecture, so you can tell at a glance which upstream a build corresponds to.

The repository is not archived, the default branch is live rather than main, and the last push was on 2026-10-20.

The preferences and flags that come after installation

Some additional preferences are added to the security settings page, providing extra security and privacy controls if they are needed. The example given is the Network Service Sandbox, disabled by default, which is known to occasionally clear cookies on exit. There is also a Website Dark Mode preference added to the appearance settings page.

Then there are the flags, and the documentation is clear that these are a different category. The following flags provide extra hardening but may cause breakage or usability issues, and they are the show-punycode-domains and clear-cross-origin-referers flags.

Punycode is the homograph attack defence, showing the unicode form of a domain so a lookalike domain is visible rather than hidden. Clearing the cross-origin referrer cuts information that a page can learn about where you came from, at the cost of some sites losing the ability to tell that they were arrived at by a link.

And then there is the compatibility side of the same mechanism. Other flags are provided for compatibility should you experience an issue related to some of the hardening enabled by default. The example is the default pop-up blocker, which is very strict and may optionally be disabled with the strict-popup-blocking flag to improve usability.

So the pattern is consistent throughout: the hardening is on, and a documented escape hatch exists for each piece.

Content filtering, and a list that is somebody's job

Trivalent comes by default with content filtering enabled, using Chromium's internal subresource filter, and the lists used for it are pointed at in a separate repository under a script.

Two things follow from that design. First, the mechanism is Chromium's own, not a bespoke blocker, which means the filtering runs at the network layer on subresources rather than by rewriting pages, and it inherits whatever Chromium's filter format supports. Second, the list itself is maintained separately, in the trivalent-subresource-filter repository, and that repository is where you go to suggest a new list or contribute to the filtering.

So the content blocking is a data problem layered on a stable Chromium mechanism. The list can be updated independently of the browser build, which is a sensible separation when the browser is a quarterly Chromium rebuild and the list wants to change daily.

The trade-off is the usual one for a blocklist. It is a list of sites, so it will have false positives on sites that share infrastructure with blocked ones, and a false positive on a site someone needs is exactly the case that pushes a user to the compatibility flags above.

The selinux directory in the repository is also worth noting. It suggests the project ships policy configuration for SELinux alongside the browser, which is consistent with a project that cares about what the browser process is allowed to do on the system rather than only about what it does in the page.

Editorial conclusion

Adopt Trivalent if you run Linux desktops and want a browser that ships with a hardened default configuration, extra network controls and content filtering, without maintaining a browser build of your own. Do not adopt it expecting a full feature browser, since the project explicitly rules out functionality unrelated to security and rules out changes that trade security for privacy. Before you install, check three things: that the system you are on is one secureblue tests, since support means tested rather than permitted, whether the default content filtering interferes with the sites you use, and that you understand the compatibility flags, since the hardening is strict enough that the default popup blocker may need to be turned off for some workflows.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. secureblue/Trivalent on GitHub