Thank you very much for keeping me updated to the new UX research on Tor launcher.
Linda’s paper is inspiring. I have had several thoughts in my mind on how to improve the UX of the current anon-connection-wizard. I hope I can implement those thoughts as soon as possible so that anon-connection-wizard will not block the release of Whonix14.
I am thinking about switching the current torrc_page to the one shown in Linda’s paper (Fig4 g, which is on page 8).
I also kind of like the “process bar” in Linda’s paper indicating which page users are at and how many configuration have been or will be done. This will give a user a general feeling on how much work they have done/will do, which may reduce their uncertainty on how much options do they still have to choose and let them have a general impact on what anon-connection-wizard can help them do.
I also kind of like the idea shown in the paper that further options will show up in the same page right after a checkbox is clicked. However, this feature cost almost a redesign of anon-connection-wizard and may not improve the usability that much so let’s set the priority as low.
The instructions on description and options in anon-connection-wizard should also be improved. Small work but big improvement, so I will set the priority as high.
Disclaimer can be abandoned for next release. So let’s keep only repository.
In theory, that seems nice-to-have. In practice… Priority change. Pretty low priority. I recommend not to spend time on it. You probably have you hands full with tor-connection-wizard gui?
Unfortunately, due to personal reasons, I cannot spend as much time on Whonix as I used to spend. Whonix 14 release which includes port to Debian stretch / Qubes 4.0 lags far behind. We need more focus and help with Whonix core development. I’ll announce this in the coming days.
It contains a wizard page where user can get latest Tor bridges by finishing a challenge-response test. However, this means a clear net connection to the BridgeDB server. I am not sure whether this behavior will harm the anonymity and will be allowed in a anonymity-focused distribution.
Other features are fortunately implemented in the latest anon-connection-wizard.
I like the idea that explicitly tell users if you are living in country A, B or C, you need to configure obfs4 etc. I will add the instructions to anon-connection-wizard soon
If Tor Project thinks that’s alright… Let’s follow their turn.
To access clearnet on Whonix-Gateway…
sudo -u clearnet some-cmd-here
We could either run a script under user clearnet (preferable) or whole tor-connection-wizard under user clearnet (more risky - in case of clicking links in the gui, we don’t want some [yet to be developed] operating system standard feature to open a remote website).
anon-connection-wizard is using bridges_default file to ship the default bridges.
The default bridge used by anon-connection-wizard should be exactly the same bridges contained in bridge_prefs.js shipped with the latest TBB. This is because:
the servers hosting default bridges are set up for huge amount of traffic;
the servers hosting default bridges are probably audited by TPO for better security;
using a different set of bridges will distinguish the anon-connection-wizard bridge users from the TBB bridge users, which compromises their anonymity.
We need a mechanism to synchronize the latest bridge_prefs.js. The following are two ways:
Create a mechanism that automatically convert the bridge_prefs.js to the current bridges_default formatt. Then ship the bridges_default file;
Modify the current bridge parser to be able to extra the bridges from bridge_prefs.js. Then ship the bridge_prefs.js file.
The first solution grantees the bridges_default file shipped to users will work. The difficulty of it will be the implementation of almost full automatic mechanism. (Otherwise, it will be pretty time/effort consuming to detect/extra/update the bridge information manually every time.)
The second solution will heavily relies on the format of bridge_prefs.js file which is controlled by TPO, not Whonix. Maybe a well written RE will be fine to adapt minor changes, however, the risk of be broken after a automatic update can not be eliminated.