Skip to content
تُعرض هذه الصفحة بالإنجليزية.الترجمة العربية مُهيّأة ولكن لم تُكتب بعد. لا شيء هنا مُترجَم آليًا، لأن ادعاءً أمنيًا مُترجَمًا خطأً هو ادعاء كاذب.اقرأ بالإنجليزية

GUARDTALKOS · THE QUIET ENDPOINT OF THE GUARDTALK MOBILE PROTECTOR · ALPHA

A phone that goes quiet

GuardTalkOS is a hardened Android build with zero direct internet access. No browser, no store, no sideloading, no Google services. Wi-Fi reaches one thing: the GuardTalk Gateway you own and hold. It is built in the GrapheneOS hardening lineage for a narrower, harder job — and it is alpha.

Privacy locked, spies blocked.

The network isn't hardened. It's gone.

Commercial spyware arrives and leaves over the network: a malicious link, a zero-click payload, a silent beacon home. GuardTalkOS doesn't harden that surface. It removes it.

Wi-Fi exists only to reach the Gateway. There is no cellular data path. There is nothing to phish into. Anything that wants out has to cross a boundary you physically control.

Every stage of that chain needs a component on the device. A link needs a browser to open it. A zero-click chain needs a messaging surface that will accept an unsolicited payload. A beacon needs a route out to a command-and-control server.

liveThose components are absent from the image, so the delivery channels they carry do not exist on the device. A channel that does not exist cannot be exploited. where this ends →

This is a removal, not a setting, and not a claim about the quality of anyone's code. It is simply a smaller device. The surfaces that remain are real and named rather than hidden: the Wi-Fi stack, the Messenger, the launcher. A working 0-day against one of those is not stopped by an absent browser.

The rest of the story belongs to the Gateway. Traffic the phone is allowed to send still has to pass a device you own. Inspection and blocking happen there, not here.

The quiet phone: a standard phone's network surfaces, and GuardTalkOS with one linkOn the left, a standard phone with nine live paths off the device: cellular data, browser, push, app store, sideload, Bluetooth, NFC, USB debugging and location. On the right, GuardTalkOS: the same nine paths are absent, and one link remains — Wi-Fi to the GuardTalk Gateway, across an air gap. The Gateway is the only network peer.A STANDARD PHONEcellular databrowserpushapp storesideloadBluetoothNFCUSB debuglocationGUARDTALKOScellular databrowserpushapp storesideloadBluetoothNFCUSB debuglocationWi-Fiair gapGateway
Text equivalent · Nine delivery and exfiltration paths that exist on a standard phone are absent from GuardTalkOS. One link remains: Wi-Fi to the GuardTalk Gateway, across an air gap. The Gateway is the device's only network peer.

What's removed, and what's enforced.

Seven statements, and the mechanism behind each one. Every row below names the component that is absent or the mechanism that is enforced. Each carries the state it is in today, and each states the limit that comes with it. A row a phone reseller could have written has been rewritten until they could not.

Removal and enforcement are different kinds of claim, and they are worth separating. A removal is settled by the build tree. The component is not in the image, so the path it carries is not there to attack. An enforcement depends on configuration that can regress between releases, which is why its state is checked per release rather than asserted once.

The states are not editorial. They are read from one file, content/status.json, which also drives the status board and every label on this site. An item moves from planned to alpha to live when a person promotes it there, and the changelog carries the date. Nothing on this page runs ahead of that file.

No Google services

live

Google Play services and any re-implementation of Google services (including microG) are absent from the build.

Limit · Absence of Google services is not anonymity — the remaining surfaces are covered in the threat model.

Browser, Bluetooth, NFC, USB debugging, sideload and location paths stripped

live

The components are not built into the image, so the delivery channels they carry do not exist on the device.

Limit · The surfaces that remain — the Wi-Fi stack, the Messenger, the launcher — are real and can carry a well-resourced 0-day.

Wi-Fi: Gateway-only

live

The only network peer the device is configured to reach is the GuardTalk Gateway. No cellular data path is offered.

Limit · The OS does not inspect traffic — the Gateway does. Without the Gateway there is no checkpoint.

Custom verified-boot key, held by you

alpha

A custom AVB key (avb_pkmd.bin) makes the trust anchor one the user generates and holds, not one the vendor keeps.

Limit · Verified boot attests the OS image, not the bootloader, radio or baseband firmware beneath it.

The AVB key workflowWhere this ends// confirm §19.2 — enforcement state per release

SHA256SUMS published per release

live

Every release publishes a SHA256SUMS file and a signing-key fingerprint on clearnet. Images move over Tor once that target ships.

Limit · Verification proves the build is ours. It does not prove ours is free of bugs.

Reproducible builds

planned

A reproducible-build target so a third party can rebuild the image and reach the same hashes.

Limit · Not shipped. Until it is, a hash proves the artefact matches ours — not that ours matches its source.

Tor-only distribution

planned

Images and OTA packages are to be distributed from the releases onion only; clearnet carries the hashes and fingerprints.

Limit · Tor hides network location from most observers, not from an observer correlating both ends.

The releases onionWhere this ends// confirm §19.7 — onion address and fingerprint
// confirm §19.2 — every state against the build tree before shipRead the full catalogue

One layer of one system.

GuardTalkOS's protections are properties of the system it belongs to. The Gateway inspects and blocks; the OS makes sure there is no other way out. Without the Gateway, GuardTalkOS is a stripped ROM — and we'd rather tell you that than let you find out.

The division of labour is worth stating exactly. The OS removes the paths — no cellular data path, no browser, no store, no sideload — and configures a single network peer. The Gateway carries every defence that has to see traffic: inspection, blocking, the kill switch, the Tor transport beyond it.

Protects against

Wi-Fi is configured to reach the GuardTalk Gateway and nothing else, so traffic leaving the device meets a boundary the user owns and holds.

Limit

The OS does not inspect traffic — the Gateway does. Without the Gateway there is no checkpoint at all. What remains is a phone with one radio and nowhere sanctioned to point it.

This is also why the operating system is not sold on its own. An image installed without the rest of the system keeps the removals and loses the checkpoint. That is half the protection, and it is the half most easily mistaken for the whole of it.

Where the phone's job ends, the system's begins. That second segment is documented on the system site, because it is not this surface's claim to make. Read the Gateway and the full threat model there.

The air gap, cut to the operating-system layerGuardTalkOS connects over Wi-Fi to the GuardTalk Gateway only, across an air gap. Beyond the Gateway the chain continues through the Gateway's defences and Tor to the destination; those segments belong to the system, not to the operating system, and are shown greyed.THIS SURFACETHE SYSTEM — GUARDTALK.IOGuardTalkOSthe quiet endpointWi-Fiair gapGuardTalk Gatewayyou own it, you hold itGateway defencesTorWithout the Gateway, GuardTalkOS is a stripped ROM.
Text equivalent · GuardTalkOS reaches one peer over Wi-Fi: the GuardTalk Gateway, across an air gap. Everything past the Gateway — its defences, Tor, the destination — is a property of the system, documented on guardtalk.io ↗.

Who this is for. Who it isn't.

This operating system is a trade, and the trade is not subtle. It buys one property: no delivery channel on the device, and no way out except through hardware you hold. It pays for that property with most of what a phone ordinarily does.

The useful question is not which build is better. It is which adversary is yours, and how much ordinary function you can give up to make that adversary's usual chain fail. For most people the cost is too high, and this page would rather say so than let a purchase say it later.

If you are choosing for a newsroom, a field team or a client, read the comparison and the threat model first. A recommendation that survives those two pages is worth making.

For

People commercial spyware actually hunts: journalists, defenders, activists, NGOs in the field. People who need zero-click delivery to fail structurally, not probabilistically, and exfiltration to be a visible, blocked event.

Not for

Anyone who needs a normal smartphone: browsing, banking, a broad app set, cellular independence. If that's you, run GrapheneOS. It is the better choice for that job, and we say so.

Don't take our word for it.

You hold the verified-boot key. Every release ships its hashes. Verification is a step this project teaches, not a badge it awards itself.

alphaThe trust anchor is a custom AVB key — avb_pkmd.bin — that you generate and hold. The image is attested against a key the vendor never keeps. where this ends →

That mechanism has a hard edge, and it belongs here rather than in a footnote. Verified boot attests the operating-system image. It says nothing about the bootloader, the radio or the baseband firmware underneath it. Those sit below the OS and outside its reach.

liveEvery release publishes a SHA256SUMS file and a signing-key fingerprint on clearnet, so the artefact can be compared against the one we published. where this ends →

A matching hash proves the build is ours. It does not prove ours is free of bugs, and no amount of hashing turns an alpha build into a proven one.

Two further pieces are targets, and they stay labelled as targets. A reproducible-build target is planned. Until a third party can rebuild the image and reach the same hashes, a hash ties the artefact to us, not to its source. Tor-only distribution is planned too: images and OTA packages are to be served from the releases onion, and clearnet carries hashes and fingerprints.

There is no download control anywhere on this site, and there will not be one. The source is published so that none of this has to be taken on faith. The GuardTalkOS repositories and the release artefacts are the argument.

Alpha means alpha.

On-device validation is under active bisect. No stable release is claimed. Here is what is live, what is being proven, and what is planned — dated.

Alpha here is a state, not a disclaimer at the bottom of a page. The build runs, and its behaviour on target hardware is still being established one change at a time. PASS HOLD means the validation result is held, not granted.

For a reader deciding today, that has three consequences. The version string and the update cadence are not published, and this page will not invent either. We claim no audit and hold no certification. Nothing here is a basis for putting a phone in the hands of a person at risk on the strength of one page.

The card below is read from the same file as every state on this site, and it carries the date it was last moved. Where a value is not confirmed, the marker is printed instead of a plausible-looking answer.

alphaupdated 2026-08-22

On-device validation is under active bisect — PASS HOLD. No stable release is claimed.

Version string
// confirm §19.6
Update cadence
// confirm §19.4 — do not invent

Read the model before you trust the phone.

The threat model names what this operating system removes, what it cannot reach, and where the Gateway takes over. The system it belongs to is documented next door.