This article is finally bringing light to the TOR mainstream user's paradox. In some ways this is already possible but it requires "high end" tweaking and more or less professional "geek" qualities to pull off. There are a few private hidden sites that are achieving close to this level of "closed doors". By coding the TBB in the fashion the article presents, true privacy could be had by brand new users of TOR. This is some concern for me and has been for awhile now. I belong to some small private sites with a dozen or less participants each. Even with this Article's coding in place you will still have an unsaid issue to concern yourself with. Lets go with an example of a site that has 20 members that KNOW the credential to access or even find the site. Only folks that know the 50 character (new TOR code length) coded address will ever even SEE the site exists. If one of the 20 leak the credential now the site's existence is known without further controls in place. So we put up a network access firewall credential unique to each member, allowing us to monitor which member specific credential is employed to gain access. If we suspect any member credential we disable it, and then tell the remaining 19 members what the NEW site address is. It can be moved in seconds. The response to this concern could be a U2F approach where even if you find your way to the front door, say on the new TOR system, only a unique U2F credential for each member would pass in. At least here only a leaked U2F device would allow access. U2F is so much better than 2FA. It would be absurd to think you could run a >25 member site and maintain true "ghost" websites. Something like the old SilkRoad will never fly on the new technology, in the sense that you would never be leak free with hundreds/thousands of users. Its beyond human ability.
For most things, I don't see big merit in attempting to keep the site address private, because that then creates an effective key distribution problem (the address), and you have to agree some kind of out-of-band mechanism for that. My view is that you have to accept that the site address becomes known, but that you are interacting with it as an exchange, not as something that serves you with web-pages which are rendered. As we know, browsers are too complex and vulnerable, so if the server is compromised, potentially so can you be. In a way it's obvious - a browser is a smart-dumb terminal onto a mainframe, and the mainframe cannot be trusted, nor can the code it asks you to run. Instead, I expect the development of structured message passing sites along the lines of EDI, with some kind of xml messages containing the content. Parsed (in code), by fairly simple open source client code (you control) which has no GUI element at that point, and which can be well sandboxed and hard to break. Subsequent inspection and displayed by some code which need have no internet connectivity itself. This way, subversion attempts have to be in terms of malformed data, which is somewhat easier to mitigate than arbitrary big complex code (the browsers and javascript world). Obviously, part of the content of those messages can include certificates and encryption to suit the people involved, so you could create closed groups.
The "key exchange" issue is a small hurdle IF the attendee's list is small and the TRUST factor is maximum. Example 8-10 members. Onion address distributed, U2F to get in, all message content PGP/GPG group distributed with no plain text on server. Onion is moved often. I realize this profile/configuration is only applicable for a specialized needs case, but it does provide a way to accomplish this. As this relates to the thread topic however; this newer technology would mean we don't have to move "onion" with regularity, which also means even small "exchange" communications would be far less burdensome. I personally wish this coding wonder was publicly available as I type this post.
