Maple still has not addressed the problem that their product’s “encrypted blobs” CAN be decrypted outside the TEE. While it is decrypted only in the TEE *during normal operation*, MapleAI can be easily compelled to decrypt the blobs for law enforcement. This can be done without any technical barriers or challenges. The root key that is used to protect all data of the enclave is *outside the enclave*, in AWS KMS.
Mark's avatar Mark
Maple provides an AI experience that is as close to the privacy of local, offline AI as possible while running in the cloud. We do this by using Trusted Execution Environments (TEE). Data is encrypted locally and only decrypted inside the TEE. If law enforcement requested a user's data, they would receive an encrypted blob. Furthermore, we offer anonymous accounts that don’t have any associated email or social media identity. We've been open from the beginning. You can see our code and technical writeups: - Source code: https://github.com/orgs/OpenSecretCloud/repositories - High level architecture: https://www.trymaple.ai/proof - Technical Deep Dive: https://blog.opensecret.cloud/opensecret-technicals/ We are already in the process of commissioning third-party audits because we know those are helpful for certain organizations. I know of no other cloud AI provider, whether it’s proprietary frontier labs or other privacy AI companies, that is more open and transparent than we are. We set the bar high because we believe this industry should be open by default. We offer state-of-the-art open-weight models with the strongest privacy protections we can build. It’s up to you to decide what risk tolerance is right for you.
View quoted note →

Replies (17)

AI prompts have to be some of the most valuable consumer data out there right now, legally and commercially. I just assume everyone is getting a piece of one of those pies and that they're lying if they say they aren't.
looks like aws doesn't even provide primitives for that. not even at the hsm level. you can verify that the environment is pristine, and you can generate keys, but there's no verifiable attestation that a key was generated in an enclave or hsm 😔
I don't like the whole "remote attestation". While some time ago, I thought the "encrypted" VMs are the future, now I think this is a goose chase. I think people should rely on hardware isolation, on hardware which they simply own.
Scoundrel's avatar
Scoundrel 2 weeks ago
True. "Trusted execution environment" is just another way of saying "trust me bro." Not good info-sec!
This felt like it was written by Legal. It never says that your data is impossible to decrypt outside the TEE, only that it isn’t done normally. Also technically true, law enforcement would receive encrypted data, but nothing about “can’t compel us to decrypt”
Interesting. This is just the chat history though, right? If they didn’t promise to store chat history then this wouldn’t have been a problem. They could’ve done client side encryption and stored these chats in their Nostr relay using nip44. And we could’ve verified that the requests that are going through are correctly decrypted only inside a TEE. Btw we store chat history on Nostr relays using NIP-PNS.
Not a joke, just not a magic trick. Client-side encryption can shrink what the relay/operator sees, but it does nothing for metadata and it definitely doesn’t save you if the root key lives in KMS and can be compelled. Different layer, different failure mode.
Dakota Brown's avatar
Dakota Brown 2 weeks ago
Probably better than just straight up ChatGPT tho