Comment by internet_points
1 day ago
> you're still exposing your data to Confer
They use a https://en.wikipedia.org/wiki/Trusted_execution_environment and iiuc claim that your client can confirm (attest) that the code they run doesn't leak your data, see https://confer.to/blog/2026/01/private-inference/
So you should be able to run https://github.com/conferlabs/confer-image yourself and get a hash of that and then confer.to will send you that same hash, but now it's been signed by Intel I guess? to tell you that yes not only did confer.to send you that hash, but that hash is indeed a hash of what's running inside the Trusted Execution Environment.
I feel like this needs diagrams.
> I feel like this needs diagrams.
And there's the problem.
All of that stuff is well and good, but it seems like I have to have a fair degree of knowledge and technical skill, not to mention time and effort, to confirm that everything is as they're representing. And it's time and effort I'd have to expend on an ongoing basis.
That's not an expectation I could realistically meet, so in practice, I still have to just trust them.
In most of modern life we trust to experts to some degree. I couldn't off the top of my head explain DH key exchange, I don't know if I'll ever understand elliptic curves, but I see that most of the cryptographic community understands them as good methods for many problems and if lots of experts who otherwise argue about anything will agree "what yes, of course DH is good for key exchange but that's beside the point and djb is still wrong about florbnitz keys" then it's likely DH is indeed good for key exchange.
If everyone had to understand every detail to trust in tech we would not have nuclear plants or coast around on huge flammable piles of charged lithium
In theory, you trust the "crowd" (rather than the hosting entity) because if they don't do what they said, the "crowd" should make a noise about it and you would know.
As I read it, the attestation is simply that the server is running a particular kernel and application in the Secure Enclave using the hardware’s certification. That does not attest that there is no sidechannel. If exfiltration from the TEE is achieved, the attestation will not change.
To put it another way, I am quite sure that a sufficiently skilled (or privileged: how do you know the manufacturer is not keeping copies of these hardware keys?) team could sit down with one of these enclave modules and figure out how to get the memory image (or whatever) out without altering the attested signature.
That's the main selling point of TEE though, isn't it? That what your hypothetical team could do, can't be done?
I don’t believe for a minute that it can’t be done even with physical access. Perhaps it’s more difficult.