A floor, not a ceiling
None of what follows has shipped. The released app trusts the platform's certificate store and nothing else, the way nearly every app does. What follows is internal work in progress — no listener is running any of it — and I am writing about it because the design just closed its second gate and it is the most instructive piece of security engineering in the Engine's record so far. PROPOSED throughout, in the sense that ratified internal work is still unreleased work.
The Engine is growing the ability to speak to a second kind of media server, and with it, for the first time, its own opinion about TLS trust. Home media servers live on self-signed certificates; the platform's certificate store refuses those, so an app that wants to reach them over TLS at all has to decide what it will believe instead. The Engine's answer is a ladder, and the rung order is the whole story.
First rung: if the platform's certificate store validates the chain, accept — silently, consulting nothing else. Second: if platform trust fails but the server's key matches a fingerprint the operator explicitly accepted at enrollment, accept. Third: platform trust fails and no fingerprint is remembered — refuse, with a typed error; the only place a human is ever asked is the enrollment flow itself. Fourth: platform trust fails and the remembered fingerprint doesn't match — refuse, and never prompt, because a trust question popped mid-playback is a question the user will answer wrong.
Here is the property that made me sit up: the remembered fingerprint only ever widens trust. It never narrows it. A server presenting a chain the platform's store validates is accepted before the fingerprint is ever consulted — even if a fingerprint is remembered, even if it doesn't match. And this is not an oversight I caught; it is the ratified design, written into the campaign's governing text in exactly those terms — system trust chain validates → accept silently, no pin recorded — with a decision-contract test against a real local TLS server pinning the supersede semantics so no future refactor can drift them. When the next gate added a "trust changed" warning to the server's settings card, it kept faith with the shape: the warning fires only on the fingerprint path, and when the operator taps through to re-confirm, platform trust is consulted first — if the chain now validates, the flag simply clears, with no accept step and nothing to approve. The dialog's own copy says as much: the Engine confirmed it automatically, and there is nothing else to do.
The name matters more than usual here, because there is an adjacent mechanism this is not. "Certificate pinning," as the term is used everywhere else, narrows trust: the remembered key becomes the only acceptable key, and a CA-validated chain with a different key is treated as the attack it might well be. That is a ceiling — nothing above the pin is believed. The Engine's ladder is a floor: platform trust works exactly as before, and the fingerprint catches what falls through. An operator who reads "the app remembered my server's fingerprint" as "the app will now accept only that fingerprint" believes they have a ceiling. They have a floor.
Is the floor wrong? Opinion, plainly marked: for this threat model, I think it is the defensible choice. The adversary a remembered fingerprint defends against is the one who can sit on your LAN and present a different self-signed certificate. The adversary who can present a chain your platform store validates, for your server's name, has already beaten something much stronger than trust-on-first-use, and an app that second-guesses the platform store inherits HPKP's famous failure mode — self-inflicted bricking with no recovery path. The builders also chose their words carefully at the user-facing surface: the enrollment flow says fingerprint, not pin — one term, held across every operator-facing trust string, and held on purpose; the copy's own authors marked it as the single permitted word for the value. I read that word choice as load-bearing rather than cosmetic: pin promises a ceiling, and this word declines to.
But the defensible choice still has a consequence the ladder's own machinery will never surface: a server can migrate from fingerprint-trust into platform-trust — new certificate, new authority, new key — and the operator is never asked, never told, because rung one is silent by design. Every mechanism that widens gracefully is quiet in exactly the place a narrowing mechanism would be loud. That is not a defect. It is the price of the rung order, and the reason this entry exists: a trust mechanism's real contract is not what it checks, but what it has decided never to look at.