Except that you don't need to trust anyone, entirely.
That's the point of nested VPN chains. Let's say that you have three different VPN services in the chain. The first VPN knows your ISP-assigned IP address, and the IP address of the second VPN server. The second VPN knows the IP address of the first VPN server, and the IP address of the third VPN server. The third VPN knows the IP address of the second VPN server, and the IP address of the site that you're accessing.
An adversary would need information from all three VPNs, or from their data centers and/or ISPs.
You're still vulnerable at the operating system and hardware level. It doesn't matter what you do after booting up if you're computer has already successfully been infiltrated from the Hardware/BIOS/OS initialization that always happens before.
I don't use hardware that I've purchased using my meatspace identity. The machines mainly come from yard sales and swap meets. Typically nowhere near where I've lived. And all purchased with cash. So I'm pretty confident that they're not backdoored. I have purchased SSDs from stores, but also for cash.
I'm relatively confident that Debian hasn't been backdoored. Windows perhaps, but I rarely use it, and only in VMs.
I'm not sure that I see the point. I mean, the daemon would need to run somewhere. And it'd need to render stuff. I guess that there'd be less going on, so less that's exploitable.
But no, I haven't done that.
I mainly depend on compartmentalization. This VM runs on a host that contains no information about my meatspace identity. And the machine with that information is on a different LAN.
Edit: But upon reflection, I have done something like that. Sometimes I run remote dedicated servers. Accessed via Tor (via nested VPNs) and paid with well-mixed Bitcoin. With LUKS and dropbear, of course.
If I run VirtualBox, I can basically do the same thing I do locally. I use pfSense VMs as VPN gateways, to create nested VPN chains. And then Whonix instances, which hit Tor through those VPNs. And I access the remote VMs via VRDP via SSH via Tor etc.
My first reaction on reading this is that it sounds expensive and difficult to configure. It also reminds me a little bit of how I understand tor to work - is that accurate at all?
At a superficial level, it's exactly how Tor works. Except that there's a static chain, instead of a constantly churning mix of circuits. Each of which uses a different set of three Tor relays. Also, each socket from each app uses a different circuit. And circuits, by default, only last ten minutes, and are torn down and rebuilt whenever a socket resets.
It is expensive, I suppose. In that you must pay for multiple VPN services. I probably spend a few hundred dollars per year, on average. But that's ~nothing for me.
But it's not that difficult to configure. I use pfSense VMs as VPN routers. And pfSense has a very intuitive WebGUI. To create nested VPN chains, I just successively NAT one VPN router through another. Using VirtualBox internal networks. And pfSense optimizes MTU automatically.
Once it's setup, you just run the VMs, and it works.
Except that you don't need to trust anyone, entirely.
That's the point of nested VPN chains. Let's say that you have three different VPN services in the chain. The first VPN knows your ISP-assigned IP address, and the IP address of the second VPN server. The second VPN knows the IP address of the first VPN server, and the IP address of the third VPN server. The third VPN knows the IP address of the second VPN server, and the IP address of the site that you're accessing.
An adversary would need information from all three VPNs, or from their data centers and/or ISPs.