Despite the terms ‘privacy’ and ‘anonymity’ being used interchangeably by many, and particularly by VPN marketing, I want to first highlight the key difference being that VPN connections are not anonymous but only private. Even if no payment transaction trail leads back to you. This is because the same entity connecting you to your destinations also knows your external IP. And both privacy layers (VPN) and anonymity layers (Tor, etc.) offer only end-to-middle encryption, except perhaps for accessing .onion addresses. These limitations, among others, are reason enough for me to remain weary of whole-of-system VPN solutions.
It can be said that Superman and Clark Kent are never seen in the same place at the same time, casually exposing his secret identity. A similar observation can be drawn to VPN users: Let’s say that every time your device is on you typically run an email client, IRC client, web browser and cryptocurrency node. Each of these reaching out to servers in a pattern wholly unique to your device. When you establish a VPN connection all of that traffic disappears at once on your WAN IP and reappears around the exact same time in, say, Dubai. It is obvious to any sufficiently large observer as to what has just occurred.
Unless one exhaustively tracks and remembers to close down such email, IRC clients and crypto node each time, it is possible to correlate when somebody “jumped” to a new VPN exit. Those who configure firewalls to disallow any non-VPN traffic may not expose themselves to this issue, but what when they need to change VPN exit locations (or when the VPN host decides to), when they require direct connectivity such as for navigating around known VPN IP blocks or for low latency applications? Some VPNs block various ports, such as those for VoIP telephony. Some granularity could be desirable.
Disclaimer: this is not gospel.
I would suggest a system of prioritization based on the type of traffic you need to send and receive. Then route your network traffic across a mix of the following accordingly.
The rationale for automating any network requests is that it conceals the human element, when you viewed a resource, when you might start and end your day, what times your system is in use versus not in use, your timezone. All of which gets stuffed behind an obfuscating and less interesting wall of automation. Let your computer do your web browsing for you.
Proxied (of any variety) traffic can be dealt with in a more fractured way. Try to visualize the traffic on a per request basis. The nature of the traffic should determine which snake hole it pops out of to an outside observer’s perspective. Tor is already really useful for this with running different applications through different SocksPorts ala Tor stream isolation. If you didn’t already know, something similar can be done with VPNs via split-tunneling. Further mix things up with some oldschool proxies and proxychains.
But look at what sits at the base of that priority chart: the local host! Ideally, cache locally, host locally, process locally! As much as practically possible. To build on an old analogy, if using the internet is like broadcasting your whereabouts over a megaphone, then using a whole-of-system VPN is like broadcasting your whereabouts over a megaphone… from the next room over.
The issue is not with VPNs per se. I guess I’m just an advocate for split-tunneling individual applications over VPN, in opposition of absentmindedly tossing all data-in-motion entirely over a VPN. Or through any single proxy layer. Don’t put all your eggs in one basket. The whole end-to-end situation is treacherous (more on that in The Broadest Collection Of Global Telemetry) so do what you can to encrypt as much as possible. And if that means a VPN, then great. Just respect that a VPN is not the set-and-forget solution that some make it out to be.