Open Source Implementation of Apple's Private Compute Cloud
17 comments
·November 5, 2025ryanMVP
Terretta
> the inference provider still has the ability to access the prompt and response plaintext
Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint.
BYOK does cover most of it, but oh look, you brought me and my code your key, thanks… Apple's approach, and certain other systems such as AWS's Nitro Enclaves, aim at this last step of the problem:
- https://security.apple.com/documentation/private-cloud-compu...
- https://aws.amazon.com/confidential-computing/
NCC Group verified AWS's approach and found:
1. There is no mechanism for a cloud service provider employee to log in to the underlying host.
2. No administrative API can access customer content on the underlying host.
3. There is no mechanism for a cloud service provider employee to access customer content stored on instance storage and encrypted EBS volumes.
4. There is no mechanism for a cloud service provider employee to access encrypted data transmitted over the network.
5. Access to administrative APIs always requires authentication and authorization.
6. Access to administrative APIs is always logged.
7. Hosts can only run tested and signed software that is deployed by an authenticated and authorized deployment service. No cloud service provider employee can deploy code directly onto hosts.
- https://aws.amazon.com/blogs/compute/aws-nitro-system-gets-i...
Points 1 and 2 are more unusual than 3 - 7.
Folks who enjoy taking things apart to understand them can hack at Apple's here:
https://security.apple.com/blog/pcc-security-research/
* Except by, say, withdrawing the system (see Apple in UK) so users have to use something less secure, observably changing the system, or other transparency trippers.
amelius
> Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint.
It's even harder to do this plus the hard requirement of giving the NSA access.
Or alternatively, give the user a verifiable guarantee that nobody has access.
anon721656321
at that point, it seems easier to run a slightly worse model locally. (or on a rented server)
saurik
Yes: "provably" private... unless you have $1000 for a logic analyzer and a steady hand to solder together a fake DDR module.
derpsteb
I was part of a team that does the same thing. Arguably as a paid service, but source availability and meaningful attestation.
Service: https://www.privatemode.ai/ Code: https://github.com/edgelesssys/privatemode-public
m1ghtym0
Exactly, attestation is what matters. Excluding the inference provider from the prompt is the USP here. Privatemode can do that via an attestation chain (source code -> reproducible build -> TEE attestation report) + code/stack that ensures isolation (Kata/CoCo, runtime policy).
kiwicopple
impressive work jmo - thanks for open sourcing this (and OSI-compliant)
we are working on a challenge which is somewhat like a homomorphic encryption problem - I'm wondering if OpenPCC could help in some way? :
When developing websites/apps, developers generally use logs to debug production issues. However with wearables, logs can be privacy issue: imagine some AR glasses logging visual data (like someone's face). Would OpenPCC help to extract/clean/anonymize this sort of data for developers to help with their debugging?
jmort
Yep, you could run an anonymization workload inside the OpenPCC compute node. We target inference as the "workload" but it's really just attested HTTP server where you can't see inside. So, in this case your client (the wearable) would send its data first through OpenPCC to a server that runs some anonymization process.
If it's possible to anonymize on the wearable, that would be simpler.
The challenge is what does the anonymizer "do" to be perfect?
As an aside, IMO homomorphic encryption (still) isn't ready...
jabedude
Where is the compute node source code?
pjmlp
Apple's Private Compute Cloud is based on Swift though.
kreetx
I read this and your reply to the sibling, you seem to have reputation to be sensible - what are you trying to say? If someone re-implements or reverses a service then it doesn't need to be in the same language.
almostgotcaught
This dude stays commenting on things he doesn't actually understand anything about. I have run into him multiple times in threads on what I do (compilers) and he's clueless but insistent.
mlnj
It is an implementation. As long has it behaves the same...
pjmlp
Except, the original one is behind Apple servers.
parting0163
the point here wasn't to be a complete clone of Apple's PCC.
Reading the whitepaper, the inference provider still has the ability to access the prompt and response plaintext. This scheme does seem to guarantee that plaintext cannot be read for all other parties (e.g. the API router), and that the client's identity is hidden and cannot be associated with their request. Perhaps the precise privacy guarantees and allowances should be summarized in the readme.
With that in mind, does this scheme offer any advantage over the much simpler setup of a user sending an inference request:
- directly to an inference provider (no API router middleman)
- that accepts anonymous crypto payments (I believe such things exist)
- using a VPN to mask their IP?