saurik
commented
3 years ago The core problem with us optimizing too heavily for this use case is that we are a publicly published list of servers, somewhat by definition of being a decentralized system; and so, for a similar reason to why most VPN companies are actually also bad at allowing you access to geo-blocked content (which is something most people seem to experience once they actually try it, hopping in vain--manually, I might add--around to different "servers" while finding they all have been either automatically detected as VPNs or added to public shared block lists, as the servers aren't exactly secret), we would actually be worse (as our servers are nigh-unto public, and in some real sense cheaper to scrape) :(.
The only reason this feature ever momentarily works with most VPN companies is out of shear luck of finding "fresh servers" for what is otherwise generally an annoying to scrape proprietary network; in contrast, services like Tor are often just outright blocked by major websites (hell: I've even been guilty of this at times: I blocked Tor from accessing Cyrket a decade ago). I strongly believe that Orchid nodes will be blocked (or simply discouraged with repetitive CAPTCHAs) from most of the same websites that Tor is blocked from--which notably includes most geoblocked services--and this blockage will only be accelerated by leaning into features that antagonize content providers. (BTW: in case this isn't known, the way this tends to work isn't that every site has to do a lot of work themselves: you just use a DNS realtime blacklist or download pre-coded IP tables as blocklists; there are companies that maintain these as a cheap or even free service... hell: to keep themselves honest, and avoid anyone thinking this isn't possible, Tor maintains one themselves!)
So, to the extent to which this kind of feature works with normal/centralized VPN products for small periods of time, it tends to quickly be defeated. This kind of feature then makes the UI more complex and ties the marketing of our product to a use case which we would not only never be able to guarantee the behavior of but a fight we would constantly be losing (and thereby apologizing to our disappointed paying users; FWIW, VPN companies seem to profit from this by operating in a sketchy land of "buyer beware" and trying to get people to buy into heavily "discounted" year-long or even "lifetime" accounts, which then quickly become useless to the user as they go hunting for another provider that works on a different day; they often are owned by umbrella companies that own multiple sub-brands to trick people into buying multiple accounts: none of this works for Orchid ;P)... as well as putting our already-concerning-to-some product directly into the cross-hairs of well-funded opponents (aka, Big Copyright).
One VPN company that actually seems to do "well" at this is NordVPN: they've even managed to provide access to Disney+! Someone did a deep analysis of how this worked a while back (an article which has since been deleted, weirdly, but a copy can be found on the Internet Archive). They are "linked closely with a Lithuanian data mining company called Tesonet" which also runs Oxynet, which in turn advertises itself to have "32M+ residential proxies…100% anonymous proxies from all over the globe with zero IP blocking", which the author of that analysis believes is how NordVPN is originating their traffic... and how did they get all of those IP addresses? The contention was that they seem to be stealing them, convincing random products to embed malware that attaches them to the Oxynet essentially-a-botnet.
https://news.ycombinator.com/item?id=21664692
Now, the key thing to understand here is that it isn't about having so many IP addresses... with that list you'd just block them! The idea is you have to keep those IP addresses secret and then use them carefully: they are essentially like an antibiotic, in that as you use them they lose their benefit. You thereby can't just allow users to willy-nilly use them; in particular, it is very important that you establish some level of "connection affinity" to each one, preventing the same account from being used to access multiple Disney+ accounts at the same time (which will result in an automatic ban). The solution to this, at least in 2021, requires a centralized coordinator (aka, NordVPN): they keep the list secret, ensure that the IP address can only be used by a single account at a time, and probably do some kind of LRU for a very slow rotation and reuse. A naïve directory flooded with random machines all over the world, all competing for traffic, would actually destroy this magic bypass ability.
Orchid just can't do these things. The best Orchid could hope for is that an individual provider on Orchid--maybe NordVPN!--is doing that behind Orchid's back, in which case Orchid isn't really offering much benefit on top as you'd be optimizing pretty hard to manually select that provider (undermining our token economic argument). (Note that, to the extent to which this is done well--as with NordVPN--it is something that is almost entirely done behind the scenes: they can take Disney+ traffic and just send it to a different exit node than the rest of your traffic, as that's in everyone's best interests. Your server selection, in some sense, becomes irrelevant.) Maybe at some point in the future the decentralized world will be in a better position to build such elicit "public" services, but it is in some sense a hard problem.... and, hilariously, it seems to be a harder problem than just building a website that lets people pirate geo-blocked content (which is, frankly, a better way to solve this use case).
I thereby choose to consider our direct centralized competitors to be Cloudflare WARP, Google One VPN, and Guardian (now Brave) Firewall... none of which (though I could see the third of these providing such... I don't see it in their UI anywhere, though) offer a way to manually select locations or servers (which, FWIW, is actually what you really always end up having to do, and which happens to undermine our token economics). My belief is that our product really needs to lean into doing the things it can be good at (some use cases for we haven't even really been able to discuss yet as we need to whittle the product we have a bit) and make a more principled commitment to not worry so much about the things it can't be good at, as it is frankly a major internal distraction every time this comes up (particularly when it is the same few people who bring it up again and again ;P). Watching the commitment to which companies like Cloudflare are able to definitively say "X is out of scope" (such as they have now for location selection numerous times) is truly inspiring, and sometimes makes me miss working alone ;P.
On the separate topic of speed/performance and location, the location of your exit shouldn't correlate directly with bandwidth; it affects latency, which will affect the rate of speed increase on many flow control algorithms, but it shouldn't affect the final bandwidth you can obtain. There are various things that are on my todo list to improve the performance of Orchid, but a manual location selection feature isn't among them? (If you care about performance--and to the extent to which it isn't something I need to work on in the implementation itself--the level of preference more needs to be given to the client so that it is in a good position to randomly hop around on your behalf and do comparisons between different potential circuits selections; this would automatically find servers that are fast rather than trying to have you manually provide information to figure that out, as that seems unnecessarily: Cloudflare WARP--and even more notably, WARP+--certainly don't require you to do any manual specification ;P.)
(PS: I'm not a "Dr.", but I am "saurik" on Telegram! That said, I am unlikely to ever be involved in real-time community management ever again, as I learned--the hard way--that it was inherently unscalable, dangerous to users, and, in the end, detrimental to the jailbreaking ecosystem. If you are having fun on Telegram, though, I guess that makes me happy ;P.)
Dear sirs, madams,
I hope life is well and that you're all having a good Monday.
I'm going to raise an issue / suggestion in here that I have already shared in the Official Community Group on Telegram. Dan Montgomery got back to me with some feedback, which I appreciated.
This is just one of the many ideas and suggestions in order to make the "country selection" feature available for a decentralised VPN as well...
Wouldn't it be possible to get a region selection rather than a specific country selection? I mean, if I'm EMEA based, I can choose to connect to EMEA bandwidth sellers, and so for APAC and the Americas. Perhaps, Orchid could split into 3 different sections / apps and let the users decide which one to use? After all, one account can be used on all devices, we just need to install the app that we need in that moment (install Orchid America for American IP addresses and so on)... Something similar to Active Directory, where you can connect to a specific server location and find your pool of users and members in there.
This will give a shortest route to a node and make the connection much faster.
At the moment, I don't seem to get any European based bandwidth sellers and I always end up with a North American IP address. The speed is about 10Mbps average but I know it can be faster, if only I had closer access to the servers.
Probably, I should specify that mine is just a "few years down the road" suggestion - but I think it's doable. Of course, there will be the need to increase the work force, and enough time building it. It seems that access to geo-restricted sites is one of the most requested functionalities from VPN users.
If you're talking about global expansion, you also need to cover all grounds and possibilities. As it has previously been said, on multiple occasions, Orchid is a step-by-step project and I think you've been doing a fantastic job so far. Although last year was considered to be one of the "ugliest" years for our generations, I can't say the same about what Orchid Labs Inc. has been doing and about all the updates you, guys, have been giving us. For that, and for your hard work, we can be nothing but grateful and hopeful that great things will follow this year.
However, I doubt that people will stop asking the question about specific country selection and "down the road" may come sooner than expected because time flies and technology advances on an even faster pace. Little do we know, we'll eventually find ourselves dealing with millions of Orchid users and they'll be wondering how to connect to the other side of the globe without the need to "try their luck", hoping to be assigned to a desired bandwidth seller / node.
Global expansion will eventually face global issues, and by that I mean trying to find ways to make everyone happy by providing, at the same time, a state-of-the-art service and solution.
For now, I trust that "Phase 1" of Orchid, i.e. a fully functional, working and widely available dVPN system, will be successful. Next, we'll probably require a more advanced way to surf the Internet so that our digital lives will be extra safe and totally free.
Being a dVPN service provider isn't enough, we need and want you to be the best dVPN service provider available on the market.
I have been thinking about ways to provide access to geo-restricted sites, such as what Tenta Browser offers, and if I'll ever come up with another suggestion (may it be just a silly and inconclusive idea), rest assured that you'll get my feedback in here.
Keep up the great work, guys! And girls! And 7!
All the best from Italy (a country that can only connect to California and Florida-based partners, apparently)
Cheers, Salvatore
PS: Dr. Freeman, come and say hello in the Official Community Group on Telegram, if you can. We'll appreciate it very much. There is a @saurik profile with your picture up but we don't know if that's legit. Anyway, if you ever come over, you may use a keyword, something like "Cydia rocks", so that we know it's really you...