What this OS protects against — and what it doesn't.

The adversary.

A protection claim without a named adversary is a slogan. This one has an adversary, and it is narrow enough to describe.

GuardTalkOS is built against commercial spyware: the intrusion tooling sold by vendors in the Pegasus and Predator class, to state and state-adjacent customers. That tooling is not a generic criminal threat. It is bought, targeted at named people, and used against journalists, lawyers, defenders and their contacts.

Three behaviours of that class shape the design.

Network-delivered exploitation. Delivery is remote. It arrives as a link, or as a payload that needs no interaction at all. It lands on whatever component is willing to parse it.

Silent exfiltration. Once resident, the tooling collects and sends: messages, microphone, camera, files, credentials. It uses a network path the person carrying the phone cannot see.

Device seizure. The phone is taken at a border, a checkpoint or a raid, and examined by people with time, tools and legal authority.

We assume this adversary can buy a working exploit for a surface that remains. We assume they can watch network traffic, and that they may end up holding the device. The design answers the first two by removing channels rather than defending them. It hands the third to the system, where duress and failsafe behaviour live.

We do not assume an adversary who has already replaced the firmware beneath the operating system. That case is real, and it is listed as out of scope below rather than quietly excluded.

Protections, mechanisms and limits.

Each row names one protection, the mechanism that produces it, and the limit that bounds it. The state beside each protection is not a judgement made on this page. It is read from content/status.json, the one file every status label on this site reads. A person promotes a state there after checking it against the build tree, and code never does.

Read the limit column as carefully as the mechanism column. It is the more useful of the two.

What requires the Gateway.

This section is not a footnote, because the point it makes decides whether the rest of the page is true for you. Several of the protections people associate with GuardTalk are properties of the system, not of the operating system.

The Gateway is the hardware you own and hold at the other end of the phone's only link. Interception defence, intrusion detection, the kill switch, and the duress and failsafe behaviour described in the family's wording all live there. None of them is an OS feature, and none of them is claimed here as one.

What the operating system contributes is narrower and still worth having: it makes sure there is no other way out. No cellular data path, no second network peer, no browser fetching on its own account. The Gateway can only inspect what is forced to pass through it, and the OS is what forces it.

Run the phone without the Gateway and you have a stripped ROM with a Wi-Fi radio and no protection at the network boundary. We would rather write that sentence here than let a reader discover it in the field.

The Gateway↗ The full system threat model↗

Explicitly out of scope.

An honest scope statement names what the design does not answer. Everything below is a real threat that this operating system does not solve. None of it is softened by anything else on this site.

Maturity is a limit.

A threat model that leaves out the state of the software is incomplete, so here it is. GuardTalkOS is alpha. On-device validation is under active bisect — PASS HOLD — and no release on this site is presented as more than alpha.

There is no public security-research track record behind this build. No external review has been published, we hold no audit, and none is claimed anywhere on this site. Mature hardened-Android projects have absorbed years of adversarial attention. This one has not.

Treat that as a limit of the same kind as the ones in the table above.

Where a hardening state has not been confirmed against the build tree, it is shown as pending rather than described. SELinux enforcement and kernel configuration are in that condition today. The row below is published so that an absent description is not mistaken for a quiet claim.

Build your own threat model.

This is our model. It is not automatically yours, and copying someone else's is how people end up protected against the wrong thing.

Three questions do most of the work. Who is your adversary, and what can they spend on you? What happens if they succeed — to you, and to the people who talk to you? What do you need the device to do every day, and what can you genuinely give up?

Answer those honestly and the answer sometimes points away from this phone. That outcome is a success of the exercise, not a failure of it. The family's threat-modelling material and the threat library sit with the rest of the documentation.

The threat library on docs.guardtalk.io↗ The system threat model↗

The honesty pledge.

If we can't tie a protection to a mechanism, a state and a limit, we don't claim it.

That is enforceable rather than decorative. Every status label on this site reads from one file, content/status.json, and a protection sentence without a state fails the build.

A state is promoted by a person who has checked it against the build tree, never by code. No page promotes one because it would read better in green.

This page is the boundary for every claim on the rest of the site, which is why each of them links back here. If you find a sentence that a mechanism, a state and a limit do not support, tell us. The disclosure address is published in /.well-known/security.txt.