71–80 of 180 posts
I am shocked at how quickly everyone is trying to forget that TEE.fail happened, and so now this technology doesn't prove anything. I mean, it isn't useless , but DNS/TLS and physical security/trust become load bearing, to the point where the claims made by these services are nonsensical/dishonest.
Earlier quoted context omitted.
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 co…
That's the main selling point of TEE though, isn't it? That what your hypothetical team could do, can't be done?
Aha. This, ideally, is a job for local only. Ollama et al. Now, of course, it is in question as to whether my little graphics card can reasonably compare to a bigger cloud thing (and for me presently a very genuine question) but that really should be the gold standard here.
I have a hybrid model here. For many many tasks a local 12b or similar works totally fine. For the rest I use cloud, those things tend to be less privacy sensitive anyway. Like when someone sends me a message, I made something that categorises it for urgency. If I'd use cloud it means they get a copy of all those messages. But locally there's no issue and complexity wise it's pretty low for an LLM. Things like resear…
Earlier quoted context omitted.
That is where the attestation comes in to show that the environment is only running cryptographically verified versions of open source software that does not have the mechanisms to allow tampering.
That's insufficient. Code signing doesn't do anything against theft or malfeasance by internal actors. Or external ones, I suppose. If the software can modify data legitimately, it can be tampered with.
Earlier quoted context omitted.
If Bob and Alice are in an E2EE chat Bob and Alice are the ends. Even if Bob asks Alice a question and she replies back to Bob, Alice is still an end. Similarly with AI. The AI is one of the ends of the conversation.
So ChatGPT is end-to-end encrypted?
The difference here is that the web server receiving a request for Confer receives an encrypted blob that only gets decrypted when running in memory in the TEE where the data will be used, which IS an end in the system.
Earlier quoted context omitted.
So ChatGPT is end-to-end encrypted?
Yes. I include Cloudflare as part of the infrastructure of the ChatGPT service.
Get a fun error message on debian 13 with firefox v140: "This application requires passkey with PRF extension support for secure encryption key storage. Your browser or device doesn't support these advanced features.Please use Chrome 116+, Firefox 139+, or Edge 141+ on a device with platform authentication (Face ID, Touch ID, Windows Hello, etc.)."
Earlier quoted context omitted.
This is false. From Wikipedia: "End-to-end encryption (E2EE) is a method of implementing a secure communication system where only the sender and intended recipient can read the messages." Both ends do not need to be under your control for E2EE.
They do if you're both the sender and intended recipient