--- title: Release Transparency framework: Private Cloud Compute Security Guide role: article role_heading: Article path: private-cloud-compute/releasetransparency --- # Release Transparency The Apple Transparency Service publishes the measurements of every PCC software release to a public, append-only log that anyone can audit. ## Overview Overview A user’s device sends a request to a PCC node only if the node’s attested measurements appear in the public, append-only log that the Apple Transparency Service maintains; that check is Node validation. Apple Silicon Release Composition and Google Cloud Software Transparency cover how each platform composes the release entry that appears in the log. The measurements Apple publishes correspond to release builds of PCC software, so the measurements a device accepts refer to an authorized build whose published artifacts security researchers can obtain. The Apple Transparency Service, which also enables Contact Key Verification, provides a log with the following properties: Security researchers monitoring the log can obtain the artifacts referenced by each entry, reproduce their measurements, and analyze the software statically by disassembling the binaries. Exercising a release beyond static analysis depends on which node produced it: researchers can run Apple silicon node software in the Virtual Research Environment, and recompute Google Cloud node measurements with the tooling in Google Cloud Research Environment. Recording a release Each entry in the log is a digest of a release: a structured record of the measurements that describe the software a node runs. Each platform composes that record from its own measurement format, and the artifacts the measurements describe are Binary transparency, so researchers can check that they match the published measurements: Whichever platform produced it, the device performs the same check against the same log: it recomputes the release digest from the attestation bundle and verifies that the reconstructed release is included in the transparency log. Release inclusion verification A consistent view of the transparency log across all clients and auditors helps ensure comprehensive inspectability. To protect against split-view attacks, where an attacker attempts to trick a user’s device into trusting a diverging log history, connections to the Apple Transparency Service route through third-party MASQUE proxies. The client hard-codes the top-level domains of these proxies, so malicious configuration updates can’t arbitrarily re-route transparency traffic. At least once a day, the Apple Transparency Service promotes a log head to a milestone. The client tracks these milestones and validates cryptographic consistency proofs back to previous milestones, confirming consistency to the beginning of the log. When a device verifies that a PCC node release is included in the transparency log, the proof falls into one of two cases, depending on whether the Apple Transparency Service generated it before or after promoting a milestone that contains that release: During the daily milestone download, the user’s device verifies that the log is consistent and confirms that previously received consistency proofs match the new milestones. Neither check should fail in normal operation. If either fails, the device alerts the user only if a new log does not resolve the inconsistency within 7 days. This grace period accommodates recovery from operational errors or software bugs that corrupt the log, while keeping any actual attack discoverable by security researchers: an attacker can’t roll back the log to a pre-attack state. Entries in the transparency log also have associated expiry timestamps that the client validates. Releases that are in use beyond the initial 14-day lifetime are republished to the log with a new expiry. For additional details of the protocol, see Appendix: Transparency Log. Where a Transitive Trust validates on the device’s behalf, the same inclusion verification applies, but the device performs only part of it. A proxy node attestation carries a single transparency proof — that the proxy’s own release is included at a specific log revision — and validating it commits the device to that revision as its Trusted log revisions for any downstream worker node. The proxy keeps that proof anchored to a revision containing the currently unexpired releases and validates worker node attestations transitively against it, so a node whose release was added after the proxy’s revision is not eligible to serve that device’s requests until the proxy refreshes its trusted revision. This holds for worker nodes on either platform. Because the transparency log is append-only, corruption might require creating a replacement log populated with current data. If this occurs, Apple publishes a note on security.apple.com explaining the circumstances that required the replacement, and the Apple Transparency Service continues to provide access to the previous log for inspectability. Apple Intelligence Report The Appendix: Apple Intelligence Report shows users the software components running in Private Cloud Compute. The report includes the attestations the user’s device validated for each request it submitted to Private Cloud Compute, covering nodes on both platforms. Each attestation carries the measurements of the release the node was running, along with an inclusion proof for those measurements in PCC’s transparency log. The bundle that carries those measurements differs by platform: For more details on how to inspect the transparency log, see Inspecting Releases and Appendix: Transparency Log.