I don’t approve of the attitude of the forum thread starter but this again highlights usability issues.
While usability for onion services has room for improvement, on the other thand this applies to other aspects of Whonix too. Understanding what Whonix is and Installation of Whonix is still something most people fail at. Whonix-Host will help with usability since Whonix becomes a “standard conformant” Linux distribution available as iso. It also helps with security since then host security improvements are easy to deploy as probably few follow all host hardening instructions.
I was thinking about this.
There are some issues with scripts for improved usability. These add a level of mysticism as people start to think the functionality is dependent on the functionality of the scripts. Things the script does not ever then starts to seem impossible. Technical background that was previously simple gets mystified. People stop looking at the actual generated configuration files.
For example for Onion Services Authentication which is probably too difficult to manually set up, I created some scripts:
- man anon-auth-autogen
- man anon-server-to-client-install
But in case that breaks in future or doesn’t work in some case, can someone look at the actual config files or even send bug fixes for these scripts?
Also the bug of duplicate parsing of torrc in this thread wasn’t caught by anyone which was caused by anon-connection-wizard modifying Tor config files.
An onion services usability script… Where does it start and where does it end? Should it support just 1 thing. Onion web server? Server on non-standard ports? Onion services authentication? I am wondering what’s the best way to implement this? Related to Focus on low-effort maintainability.
- Implement declarative? I.e. Tor config file snippets which get copied [or symlinked if that is possible]) once the script runs? That is easier code, easier to review/understand but more limited as only a few use cases could be simplified that way before too many config snippets get hard to manage / too much.
sudo apt install anon-gw-onion-server-web- that package shipping the required config snippets? That would allow for an easy/clean implementation but there can’t be thousands of packages supporting all use cases.
- If going that way, there then could be a companion package
sudo apt install anon-ws-onion-server-web.
- Implement functional? I.e. similar to anon-auth-autogen? Then any non-standard things (non-standard ports, something other than default webserver port) requires the script to be run with a parameter. And this script will become more complex/lengthy since it has to handle these variables.
- Similar to
sudo virtport=80 hsport=80 hsname=hidden_service client=1 anon-auth-autogen.
- Users would then more or less mindlessly copy/paste such commands from the wiki. But would that effort be useful? If it’s a copy/paste job anyhow, could instead could also just provide one-liners in the wiki. See to use or to not use One-Liners - this is the question. And then the effort for the script could be saved.
- Similar to
As for onion services usability GUI… Well, I regard a GUI a frontend. Before frontend development makes sense, there needs be a backend, the script. If the script isn’t easy to use, then it’s also not easy to write a mostly bug free GUI. By separating backend and frontend also debugging gets easier and hopefully things are also easier to understand.