151–160 of 160 posts
Earlier quoted context omitted.
they just got exploited a few days ago
they did not. the attack did not change anything about the privacy and anonymity. it isn't even an exploit, its simply using tens of million of dollar in mining costs to try doing a 51% attack and spread FUD which worked on you. this isn't reddit. if you are trying to act like a know it all at least do basic research.
crypto rubes are hilarious.
Earlier quoted context omitted.
they did not. the attack did not change anything about the privacy and anonymity. it isn't even an exploit, its simply using tens of million of dollar in mining costs to try doing a 51% attack and spread FUD which worked on you. this isn't reddit. if you are trying to act like a know it all at least do basic research.
a 51% attack poc is successfully executed and you call it FUD lmao. crypto rubes are hilarious.
I'm a huge fan of the technical basis for this. I want services to attest themselves to me so I can verify that they're running the source code I can inspect. And, well, the combination of founders here? Good fucking lord. I'm really fascinated to see whether we can generate enough trust in the code to be able to overcome the complete lack of trust that these people deserve. I can't imagine a better way to troll me o…
Earlier quoted context omitted.
I didn’t sell PIA. It was a merger to create a publicly owned privacy company and, unfortunately, the terms of the merger did not come to fruition. I left the company on principle by relinquishing my shares at a mere fraction (about 1/3) the value. I walked away from millions of dollars, and I am happy with my decision. Given what happened, we built VP so that trust is no longer required.
Nobody trusts you, mission accomplished.
Things may have changed since mid-2023 but here were my takeaways:
-----
Re: 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](https://github.com/gramineproject/gramine) and [Fortanix](https://github.com/fortanix/rust-sgx) 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).
-----
Re: Trust model
A convincing trust model for TEE VPNs was possible, but a big engineering challenge.
1. 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
*Possible solution**: A way to link the **remote attestation** to what you’re connecting to.
Re: 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](https://github.com/PSPReverse/amd-sp-glitch), [arXiv](https://arxiv.org/abs/2108.04575)) and (from my reading) it was very practical and almost unforgive-able, see [this image](https://forum-uploads.privacyguidesusercontent.com/original/...). Funnily enough, you can even see my post in 2023 to understand if the AMD VLEK addition mitigated the vulnerability ([GitHub comment](https://github.com/PSPReverse/amd-sp-glitch/issues/3)).
*Possible solution*: 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.
-----
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!
I'm a huge fan of the technical basis for this. I want services to attest themselves to me so I can verify that they're running the source code I can inspect. And, well, the combination of founders here? Good fucking lord. I'm really fascinated to see whether we can generate enough trust in the code to be able to overcome the complete lack of trust that these people deserve. I can't imagine a better way to troll me o…
The SGX TCB isn’t large enough to protect the really critical part of a private VPN: the source and destination of packets. Nothing stops them from sticking a user on their own enclave and monitoring all the traffic in-and-out. Also, the README is full of AI slop buzzwords, which isn’t confidence-inspiring.
One of the many reasons I love Mullvad (been using it for 4 years now) is their simple pricing—$5/month whether you subscribe monthly, yearly, or even 10 years out. I wanted to give your product a try, but the gap between the 1-month and 2-year plans is so big that a single month feels like a rip-off, while I’m not ready to commit to 2 years either. On payments: for a privacy-focused product, Monero isn’t just a luxu…
Which are the other reasons, and which other providers have you evaluated? Asking because I might soon be in the market.
Mullvad is the only one that have RAM-only (diskless) servers. Both Mullvad and IVPN have Monero as a payment method (which is the best for privacy) and both have Anonymous sign-up no email required.
Proton is last because they don't support Monero (only BTC which isn't very anonymous by design)
All have third party independent audits and are OSS
Earlier quoted context omitted.
Which are the other reasons, and which other providers have you evaluated? Asking because I might soon be in the market.
to me at this point I only would trust these in this order: Mullvad IVPN ProtonVPN Mullvad is the only one that have RAM-only (diskless) servers. Both Mullvad and IVPN have Monero as a payment method (which is the best for privacy) and both have Anonymous sign-up no email required. Proton is last because they don't support Monero (only BTC which isn't very anonymous by design) All have third party independent audits…
