I was trying out the new feature to choose an entry server randomly, however when i used it (for the entry server) it choose the server “Aether-gw-hu-02” while my exit node was “Aether-gw-is-01”, in other words it made me use two hops from the same operator thus arguably defeating the whole point of using nym VPN.
What makes this an issue is that it is no different from using a centralized VPN, and arguably worse since the individual operators are less known than say Mullvad, also consider that there are a few operators that control a good portion of all servers (Aether, Oceanus Staking, Pettroff Staking, Hermes Stakepool, etc.) so the chances of randomly picking two servers from the same operator is not that low.
Is there something I’m missing? Because right now using this feature seem like terrible opsec, it should make sure you’re not putting your trust on only one operator and find two servers from different people.
NymVPN disallows a user to select the same server for entry and exit, but yes indeed, there is the additional problem that two different servers might be run by the same operator - and thereby undermine the benefits of decentralization. This is why Nym is rolling out the concept of ‘node families’, so that the route selection algorithm can detect if several nodes are run by the same operator and make sure to exclude those routes. (The concept is somewhat similar to Tor’s relay FamilyID’s: Tor Project | Learn how to configure your relays' FamilyID).
Current status: Nym Node Family scheme has been conceptualised and is now being scoped for technical implementation. The scheme will be presented and explained in an Operator Town Hall soon, so if you want to know more, and especially if you are also an operator, do keep an eye out!
In the meantime, we urge users to select nodes from different operators where obvious. Do feel free to ask more questions!
I feel this info should be made more obvious, at least for the random selection mode since with it it’s impossible to “select nodes” and make sure they are from different operators, I at least didn’t know the implications from this and would have appreciated an indication that this was even a possibility when enabling random mode.
It may further reduce the chances of this happening and result in less routing computation for nodes if there was a max percent/number of nodes per family allowed per set. Has that been considered? This would ensure greater diversity of nodes in a similar but cheaper (in terms of compute) way.
Yes, good shout. The main issue remains, that until we actually have node families implemented, its not possible to verify whether nodes are indeed from the same family and warn users on that basis. So it is a best guess situation based on the naming of nodes. I have relayed to the dev team to look into putting up some warning up for at least the random route generator!
I can see how this might seem like a good thing to do, however, it defeats the point of node families: if we set a cap, that is a disincentive for operators to be honest about all the nodes they are running. We want operators to clearly mark ALL the nodes they have under their control, so that we can operate within some trust assumptions about this and construct routes that have the best chance at being through independent, unlinkable nodes.
To put it bluntly, it is better to have ten operators each running a family with thousand nodes each and honestly declaring these, than it is to have a cap of ten nodes per family, resulting in a thousand families where it is kind of dubious if they are indeed run by different operators.