Yes more than happy to weigh in, thanks for the ping @Niek-de-Wilde! (always feel free to ping me on relevant things on Privacy Guides!)
I actually spent a few months prototyping SGX/SEV things before setting on the MPR scheme. Things may have changed since mid-2023 but here were my takeaways:
Vendor lock-in
Vendor lock-in is (was?) a huge problem (at least for process-based TEEs)
Process-based TEEs (mainly SGX) operated by providing essentially a whole new system abstraction. At the base level, there was no libc-like or POSIX-like interfaces, only Intel specific ones. This is why there are projects like Gramine and Fortanix that aimed to provide a more libc/POSIX-like interface to developers, even though this was the leakiest of abstractions (you can’t even create a UDP socket).
This is not only a problem in terms of Developer Experience though, this is also a huge problem for vendor lock-in. Porting things were nigh impossible, and you’re stuck with the Intel platform. I think Intel is making a genuine attempt at making a good TEE right now, but what if Intel decides to axe their budget for TEEs or drop support altogether?
Possible solution: Use VM-based TEE abstractions like SEV or TDX, which can run a full VM, which is at least a more portable solution and has a full Linux environment (with some caveats).
Trust model
A convincing trust model for TEE VPNs was possible, but a big engineering challenge.
- TEEs without remote attestation and reproducible builds of the backend are near-meaningless: If a VPN operator hands you a proof co-signed by Intel that they’re running in SGX… so what? They could simply be running a data-harvesting pipeline in SGX.
Possible solution: A remote attestation of what they’re running, which requires that they have a reproducible build of what they’re running, and for the remote attestation to verifiably attest to that reproducible build
- For VPNs: it is always possible to hand the user a remote attestation to one server, then just swap out that server for another when the user is connecting.
Possible solution: A way to link the remote attestation to what you’re connecting to.
Vulnerabilities
Back in mid-2023, it seemed like vulnerabilities in different TEEs were still popping up. However, I don’t want to overstate them here or engage in FUD: over time, it seems like the newly revealed vulnerabilities were becoming more and more theoretical attacks hard to carry out in the real world.
I think this is something that improves over time as the different TEE platforms matures, but relying solely on TEEs to make claims about privacy and security seemed a bit shaky to me.
This was the final straw for me for why not to start with TEEs back in 2023: Given that we wanted to avoid vendor lock-in as much as possible, we only had AMD SEV as a choice at the time. I came across this vulnerability (GitHub, arXiv) and (from my reading) it was very practical and almost unforgive-able, see quoted TL;DR in image below. Funnily enough, you can even see my post in 2023 to understand if the AMD VLEK addition mitigated the vulnerability (GitHub comment).
Possible solution: Okay this one was very big brain and shared with me by a venerable security researcher: MPR but each hop is a different TEE implementation 
. That way an attacker would have to have an exploit for all the TEE implementations to break the security model.
Conclusion
Anyway, these were my thoughts back in 2023, things like hardware vulnerabilities may have changed since then, and certainly the availability of Intel TDX (another VM-based TEE) makes vendor lock-in much better, but the “Trust Model” challenges still remain. That is a big engineering challenge though, and not a fundamental problem with TEEs, so I’m very cautiously optimistic!
