What's stripped, what's enforced, what's still being proven.

GuardTalkOS removes delivery channels instead of hardening them. A component that is not in the image cannot be reached by an app, re-enabled by a setting, or misconfigured by a user.

The rule behind this section is permanent, and it reads better as identity than as a feature. GuardTalkOS will never ship a browser, a store, a sideload path or direct internet access. These are not roadmap items held back for a later release, and they will never appear in a planned row on this page.

There are no Google Play services in the build, and no re-implementation of them. microG is not shipped, and shipping it later would break the same rule. Nothing on the device calls a Google endpoint. The client code that would place the call is absent.

Stating a hard negative as identity is a habit borrowed from grapheneos.org ↗, which publishes its own absolute rule about Google services. The reasoning is upstream's rather than ours, and it applies here for the same reason it applies there.

The device is configured to reach one network peer: the GuardTalk Gateway. No cellular data path is offered, so there is no second route to harden, monitor or misconfigure.

Wi-Fi here is not a general network interface. It is the link to one appliance the user owns and holds. Nothing on the device is configured to reach an internet host directly. No push transport runs, because no service holds a path to one.

The operating system does not inspect what crosses that link. The Gateway does. The OS contribution is narrower, and worth stating exactly: there is no second way out.

Without the Gateway, GuardTalkOS is a stripped ROM. That sentence is on the home page for the same reason it is here. The headline protections are properties of the system, not of the image.

GuardTalkOS is a hardened Android build produced from an AOSP tree.

The build produces four images from the GuardTalkOS OUT tree: system, system_ext, product and vendor. Those four are what this project compiles and ships for a release.

Everything else in the chain comes from elsewhere. bootloader, radio, boot, vendor_boot and dtbo are factory images, and the next section keeps them separate rather than folding both sources into one claim.

The build targets, the OUT tree and the signing step are documented on Build it yourself. A partition named on this site should be traceable to a build target there. A name without one is a defect worth reporting.

A GuardTalkOS device boots images from two sources. An honest description keeps them apart, because they are built by different parties, signed by different parties, and fixed by different parties.

GuardTalkOS pairs its four images with the factory images for one device at one firmware level. The pairing is per device, and it is recorded per release rather than assumed across a family. The device side of that pairing is on Target devices.

Because boot is a factory image in the current pairing, the kernel on the device is the factory kernel for that firmware level. This catalogue therefore makes no kernel-hardening claim on any of its nine sections.

// confirm §19.2which partitions a release signs, and with which key

The trust anchor is a key you generate and hold. avb_pkmd.bin is the public-key metadata written to the device, and it is what the bootloader checks an image against before it boots.

The arrangement matters because of whose key it is. A vendor key makes the vendor the party you have to trust. A user key moves that position to you, and it is why this project can say it holds no key that unlocks your device.

The enforcement state per release is not published here yet.

// confirm §19.2verified-boot enforcement state per release

Until that is confirmed against the build tree, this section describes the design and not the result. The workflow — generating the key, writing it, re-locking, and reading the key hash at boot — is taught on Verify before you trust.

Every release publishes a SHA256SUMS file and the fingerprint of the key that signed it. Both live on clearnet, where they can be read, quoted and compared without Tor. The images themselves move over Tor once that target ships — it is planned, and the row below says so.

The split is deliberate. The values a reader needs in order to check an artefact are small, public and worth mirroring widely. The artefact is large, and moving it over Tor keeps its retrieval off a clearnet path and off a vendor content network.

Two of the rows below are targets rather than features. Reproducible builds and Tor-only distribution are planned, and this page prints them as planned until the release process actually performs them.

The published values are listed on Releases. The step-by-step check, including what a correct result looks like, is on Verify before you trust.

This section carries no description, and the row is shown rather than dropped.

The SELinux enforcement state and the kernel configuration of a release are not published here. Neither has been confirmed against the build tree. Writing "SELinux enforcing" here without that confirmation would be precisely the unattributed sentence this catalogue exists to avoid.

Two facts bound the gap. boot is a factory image in the current pairing, so the kernel is the factory kernel for that firmware level. Anything past that — policy deltas, configuration, hardening options — is unstated rather than implied.

The row stays visible so that its blankness reads as an open question and not as a claim. When §19.2 resolves, the state changes in content/status.json first, and this page follows it.

// confirm §19.2SELinux enforcement state and kernel configuration per release

A GuardTalkOS device ships a boot animation, wallpapers, launcher icons and app icons as one palette-locked asset pack. It is a real, minor, shipped difference, and it is listed last for both of those reasons.

It appears in the catalogue because the catalogue is meant to be complete about what differs from a plain build. It does not appear because it protects anything. A device running GuardTalkOS looks like GuardTalkOS, which is convenient and nothing more.

It is not an integrity signal. Anyone holding the asset pack can reproduce the same boot animation over another image. The checks that answer "is this the build I installed" are the verified-boot key hash and the release hashes, not the artwork.

Screens that are not yet real appear nowhere on this site. Where an on-device screen is still pending on-device PASS, the site publishes a diagram instead of a mock screenshot.