There’s nothing which would cause an otherwise competent business leader to even realise they don’t understand the limits of any given security system, never mind knowing who to ask for advice.
Especially, they arguably lack the expertise to do remote hosting right. Also, as spurgu says, because they don't want stuff hosted locally. And if they thought it through, they wouldn't want the traffic back to their location.
Given all that, they arguably figure that these shared-hosting sites must know what they're doing.
I also checked out your site. I hope to be at your level of expertise one day.
Hosts are assigned a dns name <id>.onion so clients can connect to that service.
So by 'hosting' they mean being the rendezvous address?
Each of those .onion sites would have its own Tor entry guard relays, and would negotiate its own rendezvous points. An .onion service, just like a Tor user, selects a few entry guards that it uses consistently. And gradually replaces with new ones, over some weeks. But rendezvous points get picked fresh for each client-server connection.
"Chat lines" are hosted on telephone networks and inaccessible outside it.
I actually gave it a quick thought that I was curious how the hostnames were assigned but posted right before bed.
Many would love having DNS for .onion addresses. And there's been much talk of a .onion domain.
I'd forgotten that :(
And yes, v3 is a huge space. That is, several orders of magnitude larger than the IPv6 space. Which is itself humongous.
Edit: Oops. Got that very wrong. Onion v3 is orders of magnitude greater than IPv6 /64. But orders of magnitude less than IPv6 overall. It's like this, I think.
onion v2: ~1.84×10^19 [16^16]
IPv6 /64: ~1.84×10^19 (which is why OnionCat works)
onion v3: ~9.35×10^27 [56^16]
all IPv6: ~3.40×10^38
Even though you're new to all this, for others wanting to do this programmatically, there is Stem for Python and I've written one for Go [0]. It's such an easy self-hosting NAT traversal technique, I'm surprised it's not used more often in situations not requiring great bandwidth/latency (e.g. p2p chat).
Talk to the Dread Pirate Roberts next time he's in the neighbourhood.
However, Tor is vulnerable to traffic analysis. And running a server, adversaries can easily modulate/fingerprint the traffic, which facilitates traffic analysis. If you can see the signal, and have taps on major AS, you can drill down to the server.
One can route Tor traffic for .onion servers through VPNs, or even through nested VPN chains. That makes it a little harder, because the hosting provider can't easily tell that it's Tor traffic. Also, one can run a private obfsproxy, which isn't listed or indexed by Tor.
Naturally there are still risk with using a hosting service even when all information is intended to be public. The owner might change the content (integrity of the data), and it might be removed (denial of service), which is trade off for the convenience of not having to host it yourself and the uptime of 24/7 servers.
Plus it has built in side-effect anti-DOS properties so no need to centralize through companies like cloudflare.
There's huge benefits to hosting on tor even if it's just a regular website. None of my websites hosted on tor are illegal in my country.
But even with backups, the .onion private key has been compromised, so you can't come back with the same .onion address.