Hardware attestation can prove what software a device is running. Platform integrity services can use that proof to decide whether the software is approved. The proof is cryptography; the approval is policy.

Developments around Android and GrapheneOS show why that distinction matters for anyone who wants to build, modify, or inspect their own computer.

Who decides which operating systems are accepted?

Android hardware attestation provides cryptographically verified information about a device and its operating system. Google Play Integrity adds a platform-controlled policy layer: an alternative OS can preserve verified boot, a locked bootloader, and hardware-backed security yet still be rejected by an application because its configuration is not approved.

GrapheneOS argues that this gives Apple and Google increasing control over which systems services accept (discussion). Its own reliance on hardware security, and its port to Android 17, illustrate that strong security and alternative operating systems can coexist. The dispute is over who gets to define trust.

That becomes a public infrastructure concern when digital identity wallets rely on platform vendors’ security services, as highlighted in this discussion of European digital identity wallets. The EUDI framework is broader than Play Integrity, and identity credentials need strong protection. But where access depends on a vendor’s integrity policy, that vendor joins the trust chain between a citizen and a government service.

Can independent developers keep building the platform?

GrapheneOS reports that Google replaced public Git tags for certain source code with requests through Google Forms and delivery through Google Drive, with increasingly slow fulfillment. Its allegation of GPLv2 violations remains GrapheneOS’s legal position, rather than an established court finding. The practical consequence is friction in auditing releases, reproducing builds, and maintaining downstream systems.

The project also reports that Android 17 introduced new public APIs without simultaneously publishing their implementation in AOSP, the first such release since the 3.x era (discussion). It further alleges delays in sharing security fixes for standard platform components.

Source availability and attestation affect different parts of the same problem: can you independently build the system, and will the ecosystem accept what you build? Openness loses practical value when downstream projects cannot keep pace with the platform users receive.

Can owners inspect their own traffic?

HTTP Toolkit documents Android 17’s default Certificate Transparency requirements for system-trusted certificates in apps targeting API 37. Certificate Transparency helps expose fraudulent public TLS certificates, but these requirements also complicate using a custom certificate authority to inspect HTTPS traffic on a device you control.

That affects debugging, privacy audits, reverse engineering, and security research. It follows earlier restrictions on user-installed CAs and changes to Android’s system certificate store.

Interception remains possible: HTTP Toolkit has implemented a workaround using private CT infrastructure. The cost is another layer of complexity for owners trying to understand what their software sends over the network.

Security with owner control

These mechanisms have legitimate security purposes. Together, however, they can increase platform vendors’ influence over accepted software while making independent development and inspection harder.

Three questions need separate answers:

• What software is running? Hardware attestation can provide evidence.
• Who accepts it? Services and platform vendors set trust policies.
• What can the owner do? Practical access to source, builds, and inspection tools determines how much control ownership provides.

Strong hardware security can support open computing. The danger is treating secure, trusted, and approved as synonyms—and leaving the person holding the computer with less say over what it can run.