| This is hot garbage IMO. Admittedly I haven't looked past the intro page, and comments here. Plus I have a ton of experience in this area (although have never actually operated a consumer VPN or ToR or what have you). I think the comments here about SGX trust are misguided. This isn't protecting you from deep state chip level intentional bypasses. We can at least have reasonable enough assurance in SGX per se. The average law enforcement isn't going to get to your data because of some undisclosed SGX issue. But unlike AMZ Nitro, which AIUI has a network stack which bypasses the guest OS (I believe hypervisor can see everything, which I would trust about the same as SGX), SGX requires host/guest support to pass network packets. So in Nitro you can operate the TCB entirely without (unverified, unattested) guest OS seeing anything? But in SGX the guest has to pass traffic back and forth to SGX. The difference here is who operates the untrusted bit. For SGX it's the application author themselves. That is why you need the 10ms batching, to stop the host/guest from matching src/dst pairs, and inspecting the outbound traffic (inbound is presumably encrypted for the TEE). However, batching is laughable and won't stop correlation (unless you inject significant fake traffic, which the host/guest has to not be able to tell is fake). So like every other VPN this is marketing of snake oil. Compare that to express or whoever it is that offers static IP within Nitro. That is way more useful than this pretend security. (Use of Nitro allows them to not know what static IP is assigned to you, so they can't be compelled to give that info up.) MASQUE (Apple Private Relay) or other double-blind VPNs are better and don't require SGX. Besides the technical inadequacies, you have the double whammy of PIA and MtGox heritage. oh my. |