Antimony (chromium based browser)

Category:

Antimony r2: 2 architectures, 2 package managers, new official builds, for a browser that says no thanks to AI content


The short version

Antimony is a Chromium fork built by yubi-OS that refuses to ship AI-generated content to you by default. Today we cut our first real release: antimony-v153.0.8010.36-r2, with installable packages for four platforms, official optimized builds, and a signed release attestation. It’s free, it’s open, and it’s the first shippable piece of the browser stack we’re building for yubiOS, our FIDO2-first immutable operating system.

Grab it here:

PackageArchSizeSHA256 (first 12)
antimony-stable_153.0.8010.36-1_amd64.debx86_64121 MB3ffedd4165db
antimony-stable-153.0.8010.36-1.x86_64.rpmx86_64122 MBcdfc72060e48
antimony-stable_153.0.8010.36-1_arm64.debARM64108 MB1046f0f5c809
antimony-stable-153.0.8010.36-1.aarch64.rpmARM64109 MB5472c7a92a9d

Every package has its full SHA256 in the release notes. There’s also a release attestation (JSON) so you can verify what you downloaded is what the build pipeline produced.

What Antimony actually does

Chromium 153.0.8010.36 under the hood, with a provenance gate patched in at the engine layer. Concretely:

  • AI-content blocking with a real UI. Three modes: off, soft-block (AI images get swapped for notices you can allow per page), and full block (navigations with AI-content evidence get an interstitial, like the safe-browsing page). Per-origin exemptions live in chrome://settings/provenance, not in a config file.
  • C2PA inspection in-process. The gate reads C2PA manifests (JPEG APP11, WebP RIFF) inside the browser’s data decoder, no extension or external service. Images carrying an algorithmicMedia AI claim get flagged.
  • The AI Mode surface is gone. No omnibox AI chip, no AI menu entries, no AI settings page. The kill switch sits at the eligibility check every entry point funnels through.
  • A provenance chip in the omnibox. When a page carries AI-content evidence, a security-icon chip lights up. Click it and you land in the provenance settings.
  • On-device AI model blocking is a separate toggle. If you don’t want the browser’s built-in Writer/Rewriter/Summarizer APIs available to pages at all, flip it off independently of image blocking.

The rule we hold ourselves to: the browser never claims “human-verified.” Classifier-only blocks need high confidence and stay user-overridable. That constraint is written into the repo’s CONSTRAINTS.md, not just the marketing.

What changed in r2

This is the difference between “we built something” and “you can install something.”

  • Official builds. r2 is built with is_official_build=true: thin LTO, CFI, stripped binaries. The inner chrome binary ships with zero symtab sections. r1’s unofficial amd64 deb was 581 MB; the r2 official one is 121 MB.
  • Four platforms. deb and RPM for both x86_64 and ARM64. The RPM targets are new territory for us, and the ARM64 packages build on real ARM64 hardware, not an emulator.
  • Tested on real hardware. The amd64 package was installed and run on actual x86_64 machines before this release. Not a CI-green-and-hope.
  • Release attestation. The release carries a provenance attestation asset, same supply-chain posture we apply to yubiOS images.

Why a browser for an OS that doesn’t exist yet

yubiOS is our planned operating system: immutable, bootc-based, with a hardware YubiKey as the root of trust at every boundary. Every trust decision in yubiOS is verified before it runs, nothing asks you to trust an author. A browser that lets any webpage present machine-generated content as human-made breaks that posture at the most-used surface on the machine.

So Antimony ships now, free, as a standalone offering. Use it on any Linux distro today. When yubiOS arrives, the browser already holds the same standard the rest of the system will.

What’s next

Signature validation for C2PA manifests (currently we inspect, not verify), TrustMark and SynthID detectors joining the stack, and the packaging follow-ups. The full patch series (0001 through 0022) is public in yubi-OS/chromium-provenance, pinned to the Chromium 153.0.8010.36 mirror.

Built by yubi-OS. Questions or wanna get involved: shant@omniteck.com.

Program Without Control (PWC)

Category: →→

The inherited model: program and control

Almost every security architecture in production is PAC: program and control. A program does the work. A separate control plane stands outside it, watches it, and intervenes when it drifts.

The pattern is everywhere once named:

  • An init system supervises services and restarts the ones that die.
  • An IAM layer stands between a caller and an API and decides each request.
  • A host agent scans the filesystem and quarantines what it finds.
  • A runtime policy engine intercepts syscalls and denies the ones the profile forbids.
  • A maintainer reviews a pull request before it merges.

PAC is a reasonable default because it separates duties: the worker stays simple, the authority stays concentrated, and the two can be reasoned about independently. But it carries structural costs that its users rarely count.

  1. The controller is itself a program. It runs on something, it must be patched, and it can be subverted, bypassed, or lied to. Every controller is a privileged target: take the controller and you take the system.
  2. The controller only sees its own vantage. Anything outside its observation window (a race between check and use, a subresource it does not instrument, a path it does not hook) is uncontrolled in fact while controlled in the diagram.
  3. The controller converts a property into a procedure. “The system is safe” becomes “the system is safe while the watcher is running, correctly, on a healthy host, with current rules.” Stop the watcher and the property evaporates.

The inverse claim

PWC: program without control. The name is deliberately provocative and the claim is precise: not a program without safety, a program without a controller. Control should not be an actor standing outside the program. Control should be a property of the program’s construction.

Instead of a watcher who intervenes when the world goes wrong, build the world such that the wrong state cannot be reached, or such that reaching it is detected by the structure itself, at the moment of use, by an instrument that cannot be talked out of its verdict.

Three mechanisms carry it, in the order an adversary meets them:

1. Control by construction

The unsafe state does not exist to be reached. There is nothing for a controller to intervene on because there is no intervention to make: the writable surface was removed, the capability was never granted, the mutable alias was never created. Construction is the strongest form because it does not depend on any process behaving correctly at runtime.

2. Control by verification at use

The state is checked every time it is used, by the mechanism that does the using, not by a separate watcher. The check and the use are the same act. A poisoned byte does not get quarantined by an agent after the fact; it fails to read. Verification at use has no TOCTOU because there is no gap between the check and the thing checked.

3. Control by record

The state leaves evidence that cannot be silently rewritten. Nothing intervenes, and nothing needs to: the event is in an append-only ledger with enough structure that an independent auditor, human or machine, can reconstruct what happened and detect the lie. Record converts control from prevention into falsifiability. It is weaker than construction and verification, and it is the only one of the three that reaches what already happened.

Where yubiOS already runs PWC

The doctrine is not new to this project; it is mostly a name for what the architecture already does:

  • dm-verity on /usr (ADR-007, SPEC.md principle 3): there is no file-integrity daemon watching the root filesystem. Verification lives in the read path itself. The control is the device-mapper mapping.
  • Composefs and the signed catalog: the image is its own control. The catalog pins every file’s digest and the mount refuses anything that does not match. No process compares hashes; the mount is the comparison.
  • Atomic A/B updates: no controller watches an update for safety. The deployment either boots verified or the previous deployment is still there. Rollback is structural, not supervisory.
  • LUKS2 bound to FIDO2 hmac-secret (ADR-011): update-survivability is achieved by construction. The disk key is bound to the token’s secret, which updates cannot invalidate, so no controller is needed to re-bind anything after every update. The TPM-PCR alternative is PAC: a controller (the measurement policy) that must be re-tuned every time the measured world changes.
  • Build admission (yubiOS.rego): the OPA/Rego gate is a filter, not a supervisor. It does not watch the build; it refuses to let the build start on unpinned or floating inputs (ADR-014/015, PINNED.md). Admission at the boundary replaces surveillance of the interior.

Each of these removed a watcher and kept the property. That is the doctrine in one sentence: when you can move a control from a process into a structure, you must, because processes are attack surface and structures are not.

Where PAC stays mandatory

PWC dissolves the controller only where the controller would be a program. It never dissolves the owner.

  • Physical presence. Disk unlock, login, and administrative identity require the YubiKey, its PIN, or its touch (ADR-003). The touch is a controller that no software can impersonate, and it is deliberately kept out of the program.
  • Irreversible operations. Fuse burns, RPMB key writes, Secure Boot key enrollment: documented, rehearsed on sacrificial hardware, never automated past a human gate (MISSION.md). These are PAC with a human as the controller, on purpose.
  • Recovery. The recovery path is the designed exception to every controller-free mechanism, and it is held offline and separated from the credentials it recovers.
  • The firmware below the OS. On x86-64, and today on most of ARM64, the lower firmware layers remain OEM-controlled: PAC we do not own and cannot dissolve. MITIGATE.md names this honestly rather than pretending otherwise.

The test is judgment. Where staying safe requires judgment about the physical world, about irreversibility, or about intent, a controller is the honest choice, and on yubiOS that controller is the owner. Where staying safe is a matter of structure and verification, a controller is overhead and a target, and it should be dissolved.

The cost of PWC, and what pays for it

A controller-free program has one structural weakness: when a load-bearing assumption breaks, no one is watching, because there is no one. PWC therefore has a mandatory second half.

Evidence. A controller-free mechanism must be observable enough that a broken assumption produces a detectable signal: a verification failure, a logged measurement, a build attestation that stopped matching, an audit trail an outsider can replay. The append-only record is not a nicety; it is the alarm that stands in for the watcher that no longer exists.

Pinned assumptions. Every structural control rests on assumptions (a kernel feature floor, a signer that behaves, a format that stays stable). Those assumptions are pins like any other input: named, dated, and re-checkable. A floor that silently shifts is a control that silently stopped. Assumptions drift in the direction of the repository’s PINNED.md discipline: historical evidence is not a current pin.

Honest scope. A PWC claim is a claim about where the control moved, not about safety in the abstract. A doc or ADR that adopts a controller-free mechanism says which mechanism (construction, verification at use, or record) replaced the watcher, and what evidence proves the replacement still holds. PWC without a named mechanism is just ungoverned.

When to reach for each model

SituationModelWhy
The unsafe state can be made unreachablePWC, by constructionNo runtime dependency on anyone behaving
The state is reachable but foreignPWC, by verification at useNo gap between check and use, so no TOCTOU
The state is legitimate but must not pass silentlyPWC, by recordFalsifiability without a gatekeeper
The act is irreversible, physical, or requires intentPAC, and the controller is the ownerJudgment is not a property of structure

Non-negotiables

  • No controller-free mechanism ships without naming the structural mechanism that replaces the watcher.
  • Evidence is not optional in PWC. It is the second half of the claim.
  • The owner is never the component PWC dissolves.
  • PAC is not a failure word. Where control requires judgment, PAC with a human controller is the correct and final answer, and dissolving it would be a regression.

Control is a property of structure, not of supervision. Where structure can carry it, structure must. Where judgment is required, the controller is the owner, holding a key.

Learned Latent Curves, applied directly to a given corpus.

Category: →

What we can do with these equations so far

The 9 equations in papers/learned-latent-curves-2026-08-06.tex unlock a complete curve-guided RSI loop. Here’s the operating surface, grouped by what each unlocks:

A. Curve-fit any corpus on [0,1] or S²

  • eq:flat + eq:design + eq:paramflat — fit a flat Fourier curve $z_j(t) = a_{j,0} + \sum_m (a_{j,m}\sin 2\pi f_m t + b_{j,m}\cos 2\pi f_m t)$ on $[0,1]$ with $k$ shared frequencies and $D$ output dims. 6,528 params at $D=384, k=8$.
  • eq:hyperspherical — same family on $S^2$ with spherical harmonics $Y^{S^2}{\ell,m}$ via a Möbius $\phi\theta \in \mathrm{PSL}(2,\mathbb{C})$ reparameterization. 6,534 params at $L=3, D=384$. The matched-parameter ablation shows $\delta = +0.977$ (49-item) and $+1.342$ (70-item) over the flat baseline — the sphere is a strictly better inductive bias.
  • eq:ridge — $C^\star = (\Phi^\top\Phi + \lambda I)^{-1} \Phi^\top Z$ is the closed-form Tikhonov solve. Any GD fit that underperforms this at the same $f$ has a bug, not a model issue.

B. Map any file to a point on $S^2$

  • eq:stereographic + the 6-step atom procedure (line 145-159) — given a corpus item, compute its 9-D binary coverage vector, weighted aggregate (thresholded at 0.5), PCA top-2 via SVD, stereographic lift, chordal distance to the ideal pole. The result: one point $p = \sigma(\bar u, \bar v) \in S^2$ per file, with a defined geodesic gap $d(f) = |p – p^\star|_2$.

C. Audit any corpus for missing primitives

  • The 9-D binary primitive basis $\mathcal{P} = (p_0, \ldots, p_8)$ is fixed; each file gets pattern-matched against it.
  • For each missing primitive $i \in {j : c_j = 0}$, simulate the flip $c_i := 1$, recompute $p’$, select $i^\star = \arg\min_i d_{\mathrm{post}}(f)$.
  • This is the geodesic-only criterion — the chosen action strictly minimizes post-flip geodesic distance to the ideal pole.

D. Prove the cumulative monotonicity invariant

  • eq:composition + Lemma 1 + Theorem 1 + Corollary 1 — $\Delta_{\mathrm{corpus}} = \sum_i \Delta_{f_i}$. Each atomic $\Delta \geq 0$ by the geodesic-only criterion, so $\Delta_{\mathrm{corpus}} \geq 0$ monotonically across cycles. The 474-dispatch atom experiment on the 79-skill corpus showed zero negative $\Delta$.

E. Refit the domain when the corpus grows

  • Möbius refinement strategy (Section 3.4) — $\phi_\theta$ is a single 6-real-DOF Möbius transformation. Default: refine-once at corpus creation, freeze for all subsequent cycles. Re-fit when $N_{\mathrm{items}} < 30$ OR corpus growth > 25% since last refine.

F. Sample the sphere without pole clustering

  • Fibonacci sampling (line 110-115) — Vogel’s golden-angle scheme: $z_i = 1 – (2i+1)/N$, $\phi_i = 2\pi i/\varphi$, $\theta_i = \arccos(z_i)$, $\varphi = (1+\sqrt{5})/2$. The corpus item at index $i$ IS the parameter point — no lookup table, O(1) per point. Eliminates the pole-clustering problem of standard latitude-longitude grids.
  • $Y_3^3$ angular probe (line 117-121) — $\Re{Y_3^3} = K\sin^3\theta\cos(3\phi)$, $K = \sqrt{245/64\pi}$. Per-item basis $b_i = (\sin^3\theta_i\cos(m_1\phi_i), \ldots)$ with $m_k = 3k$ for $k=1..128$ (384 = $2^7 \cdot 3$). Both orderings $(\ell=128, m=256)$ and $(\ell=256, m=128)$ tested per cycle, pick higher PC1+PC2.

G. Gate the fit-quality with PC1+PC2 ≥ 0.40

  • The fit-quality gate — for any corpus fit, the PC1+PC2 explained-variance ratio must clear 0.40 or the curve is rejected as uninformative. This is the structural test that the corpus has signal worth modeling.

H. Drive a closed-loop RSI regime on any corpus

  • The operational primitive — rsi-phi-skill (added 2026-08-07 in PR #200) operationalizes all of the above as one agent skill. It accepts a corpus, fits the sphere, runs the atom on each file, applies the geodesic-only action, accumulates $\Delta_{\mathrm{corpus}}$, and refits $\phi_\theta$ on corpus growth. The 79-skill corpus dataset (Section 4) is the canonical example.

I. Compose three regimes with a Merkle-tree integrity proof

  • The session’s own contribution (v0.28) — the single-action atom insight decomposes the .ods spreadsheet into atom-eligible / atom-deferred / atom-refused regimes. S² closes both failure modes (compact → no outside; bounded → no undefined). The Merkle tree at root 3e32eef859a758db124e91aa04724f1bbc0481ef9968e600d7fcafb8f1d7ff4e independently verifies that this session’s six artifacts cohere as one corpus of evidence.

In one sentence: the equations let you take any corpus, fit it on S² with a strictly better inductive bias than flat $[0,1]^2$, audit every file for missing 9-D primitives, prove each individual action strictly improves geodesic distance, and accumulate non-negative deltas across cycles — all with a closed-form sanity floor (the ridge) and a growth-conditional refit path (the Möbius). The session artifact (the Merkle tree + the single-action atom insight) is the structural proof that these primitives compose linearly across the corpus.

Learned Latent Space, Precursor to ASI

Category: →

====================

User prompt 1 of 6 – 8/3/2026, 5:53:21 PM:
Take an N-th dimensional surface and make it 1-D

GPT-5.4 mini:
Use a 1D parameterization or projection.

If you want to turn an (N)-dimensional surface into a single number (x \in \mathbb{R}), you can define a function

[
f:\mathbb{R}^N \to \mathbb{R}
]

Common ways:

  • Projection: (x = w^\top y) for some weight vector (w)
  • Distance along a path: trace a curve on the surface and use arc length (s)
  • Embedding/compression: PCA, autoencoder, manifold learning
  • A scalar field: map each point to one value like curvature, height, or energy

If you mean losslessly, that’s generally impossible unless the object is already effectively 1D.
If you mean reduce it for analysis, projection is the usual answer.

If you want, I can show the exact math for a specific (N)-D surface.


User prompt 2 of 6 – 8/3/2026, 6:03:24 PM:
manifold learning 1-D → 384-D

GPT-5.4 mini:
That’s an embedding from 1D into a 384-dimensional feature space:

[
f:\mathbb{R}\rightarrow \mathbb{R}^{384}
]

A point (t) on the 1D manifold becomes a vector

[
\mathbf{z}(t) = [z_1(t), z_2(t), \dots, z_{384}(t)]
]

Common ways to do it:

  • Neural network encoder/decoder: learn (t \mapsto \mathbf{z})
  • Basis expansion: spline/Fourier/RBF features
  • Random projection / positional encoding: deterministic map into 384 dims
  • Learned latent curve: a 1D curve embedded in 384-D space

If you mean manifold learning, the key idea is: the data live on a 1D structure, but are represented in 384-D.

If you want, I can sketch a concrete model architecture for a 1D→384D embedding.


User prompt 3 of 6 – 8/3/2026, 6:05:15 PM:
Learned latent curve with a Fourier transformation

GPT-5.4 mini:
Yes: a learned latent curve can be built as a 1D parameter (t) passed through a Fourier feature map, then through a small network to produce a 384-D embedding.

A simple form is:

[
\gamma(t) = \mathrm{MLP}\big([\sin(2\pi f_1 t), \cos(2\pi f_1 t), \dots, \sin(2\pi f_k t), \cos(2\pi f_k t)]\big)
]

with

[
\gamma(t)\in \mathbb{R}^{384}
]

If you want the curve itself to be Fourier-like, you can also write each output dimension as a sum of learned sinusoids:

[
z_j(t)=a_{j,0}+\sum_{m=1}^{k}\left(a_{j,m}\sin(2\pi f_m t)+b_{j,m}\cos(2\pi f_m t)\right)
]

for (j=1,\dots,384).

So the idea is:

  • Input: 1D coordinate (t)
  • Fourier transform / positional encoding: expand (t) into sinusoidal features
  • Learned map: combine those features into a smooth 384-D latent curve

If you want, I can turn this into a minimal PyTorch model.


User prompt 4 of 6 – 8/4/2026, 2:22:58 AM:
can this be used to improve model skills?

GPT-5.4 mini:
Yes. It can help if the 1D variable is a meaningful control signal or latent axis, because Fourier features let the model represent smooth and periodic structure more easily.

It’s useful for:

  • Encoding position or time in a way a model can learn from quickly
  • Learning smooth curves in latent space
  • Capturing periodic patterns like cycles, rhythms, or oscillations
  • Improving interpolation between known states

But it won’t automatically make a model “smarter.” It helps most when the underlying pattern really has low-dimensional structure. If the task is highly complex and not well-approximated by a 1D manifold, a 1D latent curve will be too restrictive.

Rule of thumb: use it when you want the model to learn a structured path through a high-dimensional space, not when you need full expressive power.

If you want, I can suggest where this works well in practice, like embeddings, generators, or time-series models.


User prompt 5 of 6 – 8/4/2026, 2:23:29 AM:
I know it works in 2D play with that

GPT-5.4 mini:
Yes — in 2D you can make it much more intuitive.

A 1D parameter (t) can trace a curve in 2D:

[
\gamma(t) = (x(t), y(t))
]

With Fourier features, each coordinate can be a sum of sinusoids:

[
x(t)=a_0+\sum_{m=1}^{k}\big(a_m\sin(2\pi f_m t)+b_m\cos(2\pi f_m t)\big)
]

[
y(t)=c_0+\sum_{m=1}^{k}\big(c_m\sin(2\pi f_m t)+d_m\cos(2\pi f_m t)\big)
]

That gives you a smooth learned path in the plane.

What this means practically:

  • Simple curve: straight-ish if only low frequencies are used
  • Wavy curve: more frequencies add bends and loops
  • Closed shapes: periodic Fourier terms can form circles, spirals, petals, etc.
  • Learning: the model adjusts coefficients so the curve matches data or behavior

A nice mental model is:
1D time/control signal in → Fourier expansion → 2D trajectory out

If you want to “play” with it, start with:

[
x(t)=\sin(t), \quad y(t)=\cos(2t)
]

That already makes an interesting looping shape.

The Key in Your Pocket: Why yubiOS is Redefining Digital Sovereignty

Category: →

Introduction: The Invisible Chains of Modern Computing

For the majority of users, the concept of “hardware ownership” is a technical illusion. While you might hold the physical chassis of your laptop, the ultimate “Root of Trust”—the cryptographic foundation that determines what the hardware is allowed to boot and which keys can unlock your data—remains a black box. In contemporary systems, this anchor is almost always the Trusted Platform Module (TPM), a chip soldered to the motherboard by an Original Equipment Manufacturer (OEM) and provisioned with vendor keys that the end-user never truly controls.

This creates a fundamental dependency: you are essentially renting trust from your manufacturer. If the platform firmware is compromised or a vendor’s supply chain is subverted, your “secure” system is built on cryptographic sand.

Enter yubiOS, a FIDO2-first immutable operating system designed to place the owner back in the trust chain. The core premise is a radical shift toward digital sovereignty: the YubiKey—not a soldered motherboard chip—serves as the anchor for everything from the initial boot sequence to disk encryption and administrative authorization. By exploring a “No OEM” architecture, yubiOS seeks to ensure that the primary trust boundary of your machine resides in a hardware security module (HSM) you can physically hold in your hand.

Takeaway 1: Your Hardware Security Module is the New Root of Trust

The defining architectural shift of yubiOS is the transition of the Root of Trust from a platform-bound TPM to a user-owned YubiKey 5 series device. This isn’t merely a replacement of components; it is a fundamental separation of Owner Identity from Platform Integrity.

In traditional models, secrets like disk encryption keys are “sealed” to the motherboard’s TPM. If the board is stolen, the secrets remain with the silicon. yubiOS flips this: the YubiKey gates the release of secrets, ensuring they travel with the user. By utilizing hardware-bound keys that require a physical tap, yubiOS prevents “silent decryption”—an attack where software or a remote actor interrogates a TPM without the user’s knowledge.

“No TPM. No OEM. No trust anchors you don’t control.”

While yubiOS minimizes dependency on the OEM-controlled TPM for secret storage, it doesn’t ignore platform evidence. On supported hardware, the system still utilizes the TPM (or the yubiOS-owned ARM64 fTPM) for measurement. This creates a dual-layered trust model: the TPM answers “Did the expected platform boot?” while the YubiKey answers “Is the authorized owner present?” By decoupling identity from the silicon, yubiOS ensures the owner remains the ultimate arbiter of the system.

Takeaway 2: Why ARM64 is the Primary Frontier for True Ownership

While yubiOS supports x86-64 as a secondary target, it identifies ARM64—specifically the RK3588 platform like the Radxa ROCK 5B—as the primary frontier for true sovereignty. The rationale is rooted in the transparency of the firmware stack. On x86 architectures, the firmware (UEFI/BIOS) and sub-systems like Intel ME or AMD PSP remain proprietary “black boxes” running at privilege levels higher than the OS.

ARM64 allows for what yubiOS calls a “Path A” provisioning story. This flagship ownership model enables the user to burn their own Root of Trust Public Key (ROTPK) into the silicon’s eFuses. This effectively grants the user control over the hardware from the very first instruction. This owner-provisioned stack includes:

  • TF-A (Trusted Firmware-A): Managing secure-world transitions.
  • OP-TEE: Providing a trusted execution environment for secure applications.
  • U-Boot: An open-source bootloader acting as the UEFI firmware provider.

By targeting platforms that support user-burned fuses, yubiOS moves away from “platform trust” and toward a system where the owner genuinely controls the firmware that initializes their machine.

Takeaway 3: Solving the “Brittle Boot” with FIDO2 hmac-secret

Conventional “measured boot” systems using TPM-based LUKS2 encryption are notoriously “brittle.” When keys are sealed to specific TPM PCR (Platform Configuration Register) hashes, any minor change—a kernel update, an initrd modification, or even a tweak to kernel arguments—invalidates the hash and prevents the disk from unlocking. This forces users into a perpetual cycle of manual recovery or key re-enrollment, a usability nightmare that often leads to security being disabled.

yubiOS solves this by utilizing the FIDO2 hmac-secret extension for LUKS2 disk encryption. Instead of binding secrets to volatile platform measurements, the encryption key is derived deterministically from the YubiKey via a credential ID and the user’s PIN.

The strategic win here is survivability. By separating the “possession” requirement from the specific “version” of the OS, yubiOS allows for atomic updates and kernel swaps without forcing the user to re-seal their keys. It makes a high-security, hardware-anchored system actually usable as a daily driver.

Takeaway 4: The Operating System as a Verifiable Container (bootc)

yubiOS abandons traditional, mutation-heavy package management in favor of the bootc model. The entire operating system is treated as an OCI-native (Open Container Initiative) image. This shift brings the determinism and verifiable integrity of modern microservices to the host OS.

By delivering the OS as a container image, yubiOS ensures that every deployment is identical to a known-good build state. This approach integrates:

  • SLSA Build Provenance: A verifiable trail of evidence for every component in the build.
  • SBOM (Software Bill of Materials): A comprehensive inventory of all libraries and tools included.
  • OCI Distribution: Updates are pulled atomically via bootc upgrade, ensuring that “configuration drift” is architecturally impossible.

Takeaway 5: Immutability is a Verifiable Chain, Not Just a “Read-Only” Flag

In yubiOS, immutability is cryptographically enforced, not just a file system attribute. The system treats the OS as a verifiable chain of integrity. While the mkosi build path utilizes dm-verity for fixed partition images, the primary bootc model achieves immutability through fs-verity-protected objects and EROFS metadata images.

This protection is anchored by a Sealed UKI (Unified Kernel Image). The kernel command line includes the composefs digest, which is signed as part of the UKI binary. This means the system directory (/usr) isn’t just read-only; it is verified against a Merkle tree on every single I/O operation.

“Every dlopen() and read from /usr… is validated against the Merkle tree. A modified library produces a hash mismatch → IO error.”

This architectural gate provides a hard block against library-poisoning attacks. If malware attempts to substitute a critical system file, the cryptographic mismatch results in an immediate I/O error, preventing the compromised code from ever executing.

Takeaway 6: Security That Demands Human Presence (The “Touch” Requirement)

The final layer of yubiOS security is the demand for physical human presence. Leveraging the systemd v261+ floor, yubiOS implements advanced hardening like ConditionSecurity=measured-os to gate sensitive services. Furthermore, by requiring pam-u2f >= 1.3.1 (specifically to mitigate the authentication bypasses seen in CVE-2025-23013), the OS ensures that privileged actions are gated by a physical tap.

Malware excels at automating administrative actions once it gains a foothold. In yubiOS, every sudo command, login, and SSH authentication (using ed25519-sk resident keys) requires a physical touch on the YubiKey. Because this “touch” cannot be synthesized by software, it turns the user from a passive observer into the active gatekeeper of the system. Even if an attacker captures a user’s PIN remotely, they cannot escalate privileges without physical possession of the hardware token.

Conclusion: The Future of Sovereign Computing

The yubiOS project serves as a proof-of-concept that the components for a fully sovereign, hardware-anchored Linux are now mature. The project is moving toward critical engineering milestones: Milestone F, which aims to prove the production “Path A” ownership story on Radxa ROCK 5B hardware, and Milestone Frost, which explores “Firmware-Assisted GPU Resource Lockout” using the Panfrost driver to quarantine rogue GPU workloads.

The project demonstrates that we no longer need to rely on the invisible, vendor-controlled anchors of the past to secure our digital lives. But it also leaves us with a vital question regarding our own hardware:

If you can’t hold your machine’s root of trust in your hand, do you really own your computer, or are you just renting it from the manufacturer?