Onto the problem
While MediaWiki is relatively linked and works great, the forums seem to be absolutely linked and this is an annoyance. Is it possible to configure SMF to also relatively link? I mean otherwise, one needs to manually copy the absolute URL to a particular SMF link, paste it and replace the actual domain for every single link.
EDIT: thinking about this further, is it even possible to actually create content (wiki articles/forum posts) via the .onion(s)? I mean, is it a two-way sync OR an alias (would somehow defeat the purpose of the onion) OR … hopefully valid questions that come to my mind here.
zo7fksnun4b4v4jv.onion is our old onion. No longer advertised anywhere. We may take it offline at some point. Our new kkkkkkkkkk63ava6.onion onion will stay. They’re both running on the same server. Just kept the old one for compatibility.
The .onion domains are just alternative domains pointing served by the same server. No mirrors.
Editing the wiki using the .onion should work well.
About .onion support for the blog and the forum, we would like it. Seems tricky, though. Unless someone can provide a shortcut of telling us how to implement it. Fortasse still has it on its list.
Another issue is, that .onion domains do not support sub domains. At least not at time of writing. It may change in a few years, how knows. I guess forum.whonix.org, blog.whonix.org would be more attractive than Whonix Forum. But we’re not aware of anyone coming up with a good solution for that in combination with .onion domains. The Tor Project uses several .onion domains for the various sub domains. I am not sure this is a better solution than /forum.
Actually it is advertised at .infobox > tbody:nth-child(2) > tr:nth-child(17) of https://www.whonix.org/wiki/Main_Page + at https://www.whonix.org/wiki/Impressum
The .onion domains are just alternative domains pointing served by the same server. No mirrors.
I see. What's the purpose of the onion then? I mean if the IP is publicly known, it isn't an emergency backup after all. Think stupid law-makers.
Unless someone can provide a shortcut of telling us how to implement it. Fortasse still has it on its list.
Thanks for the heads up. If I come across some useful information here, I'll let you know.
Another issue is, that .onion domains do not support sub domains.
I see. I'm not sure what to vote for here. If the onion is just an alias it doesn't provide any protection against "invading forces" anyways. If we'd change this, several onions for the subdomains may make sense, i.e. the forum physically isolated from the wiki, blog and so on. From a cosmetic perspective, I'm totally fine with the subfolder approach.
Actually it is advertised at .infobox > tbody:nth-child(2) > tr:nth-child(17) of https://www.whonix.org/wiki/Main_Page
Not any longer. Fixed that. Thanks for spotting.
+ at https://www.whonix.org/wiki/Impressum
This is just a legal requirement. The old onion can only be removed there, when we take it offline.
What's the purpose of the onion then?
It's purpose is a bit hidden, documented on https://www.whonix.org/wiki/Whonix:Privacy_policy in a footnote:
“Optional Tor hidden service (.onion domain); alternative end-to-end encrypted/authenticated connection; in this use case, not for location privacy; backup in case DNS is not functional”
If the onion is just an alias it doesn't provide any protection against "invading forces" anyways. If we'd change this, several onions for the subdomains may make sense, i.e. the forum physically isolated from the wiki, blog and so on. From a cosmetic perspective, I'm totally fine with the subfolder approach.
We probably won't make separate servers for blog/wiki/forum anytime soon. It's not worth it yet.
There can be no protection from invading forces. Only full anonymous development and .onion domain only could work. This isn’t an option anymore, at least not for me since the word is out. Also you might not have heard about Whonix in the first place if we took that route.
This is just a legal requirement. The old onion can only be removed there, when we take it offline.
Sure, I understand this.
"Optional Tor hidden service (.onion domain); alternative end-to-end encrypted/authenticated connection; in this use case, not for location privacy; backup in case DNS is not functional" (...) Only full anonymous development and .onion domain only could work. This isn't an option anymore, at least not for me since the word is out.
Thanks for explaining this. Actually I pushed your "outing" to the back of my mind for a second here. My mistake.
I have a workaround for accessing the forum via .onion more easily, using HTTPS Everywhere and user rules.
Paste this:
<ruleset name="Whonix Onion">
<target host="www.whonix.org" />
<target host="kkkkkkkkkk63ava6.onion" />
<rule from="^http(s)?://(www\.)?whonix\.org/" to="http://kkkkkkkkkk63ava6.onion/"/>
</ruleset>
into a file named “WhonixOnion.xml” in [Tor browser folder]/Data/Browser/profile.default/HTTPSEverywhereUserRules/ and restart the browser.
Now all your whonix.org traffic should be pointed at the onion. If you want to go back to whonix.org (and not .onion), the HTTPS Everywhere icon in the upper right will show your ruleset with a check box. Uncheck it, and continue browsing the .org!
The .onion and .org sites are identical, and edits / posts made on one domain will be reflected on the other. As Patrick said, the .onion isn’t really for privacy as it is for censorship-resistance and fallback in case DNS gets wonky.
For being a bit hacky, it’s a pretty solid solution - HTTPS Everywhere is clever and it does the rewrite before making the request, so the browser never asks for whonix.org, only the .onion.
Using xxxxxxxxxxh5kyrx.onion, forum works, wiki works, any link related to blog fails to load with a ‘Unable to connect’ error. Blog links still work when accessed via clearnet address whonix.org
It was indeed a result of the 4.0 upgrade on Wordpress.
Our wiki works well with the .onion, but because of the way most popular webapps are written, they expect to be at one location (News - Whonix Forum) and not at multiple locations.
The current equivalent is a hidden debug/test page that you can access in Firefox through about:addons > HTTPS Everywhere preferences > click under General Settings > press Ctrl-Z, or in Chrome by pressing Ctrl-Z in the equivalent place. It doesn’t appear to work in the current version of the Tor Browser. The UI is specifically intended for testing rulesets, as opposed to using personal custom rules indefinitely, but that’s what there is.
The current equivalent is a hidden debug/test page that you can access in Firefox through about:addons > HTTPS Everywhere preferences > click under General Settings > press Ctrl-Z, or in Chrome by pressing Ctrl-Z in the equivalent place. It doesn’t appear to work in the current version of the Tor Browser. The UI is specifically intended for testing rulesets, as opposed to using personal custom rules indefinitely, but that’s what there is.
Could this be used to re-add Whonix rules?
Hi Patrick!
It seems this approach is only used for testing and is recommended
against daily use. Here is a more detailed update to HTTPSEverywhere doc
for that:
Also, the trick will not work in TB when JS is disabled:
If it cannot be fixed… We should…
remove it from wiki footer
Do we have another place to document the Whonix addresses (including V2
and V3 onion services)? If not, shall we create one and then change the
footage to that page?
add __NOINDEX__ to the wiki page
add a deprecation message on top of that wiki page
Do you think not adding __NOINDEX__ is a better idea? Because there
may be users who saw this forcing onion before and want to do the trick
again. Making the page searchable, may save their time in figuring out
it is deprecated?
Thank you so much for your contribution. The instructions looks very clear to me! Good job!
Rules cannot be easily changed from the GUI, especially in the case of a broken redirect. You may need to edit rules manually.
I agree. But it seems sometime, when you are at a redirected page and click on the HTTPSEverywhere icon, there is a section called Stable Rules where one can delete the broken rules by clicking on the red X.
The stable rules section does not show up all the time however.
There is a way to continue using the old rules with the new version without having to manually enter them. Especially important if you used to have hundreds of onion rules.
As far as I know, the migration feature was added in version 2017.8.19 and removed at some later version.
Copy HTTPSEverywhereUserRules to the profile folder. Download and install this version. It should convert and store the old rules inside profile folder as browser-extension-data\https-everywhere-eff@eff.org\storage.js
Backup this file and copy to the browser profiles that use the latest version of https-everywhere.
You can manually edit the file (not easy) or repeat the same process to update from your custom rules.
A storage.js file with only Whonix onion rule converted will look like this:
Thank you so much for sharing the trick, @anonymous1 !
An potential problem is there may be a different version of that file when adding it from GUI HTTPSEverywhere, instead of doing the auto converting trick during migration and user may think they did something wrong? What do you think?
