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
This likely happened with the upgrade to wordpress 4.0. fortasse (webmaster) is aware of it. We haven’t figured out yet why it does this.
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.
If you want to browse our site using the .onion exclusively, please look at this wiki page: Forcing Onion Connections on whonix.org.
Sorry for the delay, and thanks for bringing it to our attention.
1 Like
After Forcing .onion on Project: Difference between revisions - Whonix that page Forcing Onion Connections on whonix.org which is linked from the wiki footer makes almost no sense. //cc @iry
If it cannot be fixed… We should…
- remove it from wiki footer
- add
__NOINDEX__to the wiki page - add a deprecation message on top of that wiki page
Can https everywhere be somehow fixed even without HTTPSEverywhereUserRules\ support? ( Using HTTPSEverywhereUserRules with WebExtensions · Issue #14375 · EFForg/https-everywhere · GitHub )
What about…
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?
Patrick Schleizer:
Can https everywhere be somehow fixed even without
HTTPSEverywhereUserRules\support? ( Using HTTPSEverywhereUserRules with WebExtensions · Issue #14375 · EFForg/https-everywhere · GitHub )What about…
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?
1 Like
Just updated the Wiki page with instructions that work with the new plugin. Let me know if there are any problems with my contribution.
4 Likes
Hi @9jnc7 !
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.
2 Likes
I did some minor changes to the page as well. 
2 Likes
Great!
Can we get rid of all the v2 stuff or is there a reason to keep it?
1 Like
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.
https://www.eff.org/files/https-everywhere-2017.8.19-eff.xpi
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:
{"legacy_custom_rulesets":["<ruleset name=\"Whonix Onion\">\n\t<target host=\"whonix.org\" />\n\t<target host=\"www.whonix.org\" />\n\t<target host=\"phabricator.whonix.org\" />\n\t<target host=\"forums.whonix.org\" />\n\t<target host=\"download.whonix.org\" />\n\t<target host=\"deb.whonix.org\" />\n\t<rule from=\"^https?://(www\\.)?whonix\\.org/\" to=\"http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/\" />\n\t<rule from=\"^https?://(phabricator|forums|download|deb)\\.whonix\\.org/\" to=\"http://$1.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/\" />\n</ruleset>\n"]}
But the user will lose custom rules or settings if the file is copied directly.
Providing this storage.js file would be more complete than the current suggestion.
3 Likes
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?
{"ruleActiveStates":{},"migration_version":1,"showCounter":true,"userRules":[{"host":"www.whonix.org","redirectTo":"https://www.whonix.org/","urlMatcher":"^http://www\\.whonix\\.org/"},{"host":"www.whonix.org","redirectTo":"https://www.whonix.org/","urlMatcher":"^http://www\\.whonix\\.org/"},{"host":"www.whonix.org","redirectTo":"http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/","urlMatcher":"^https?://www\\.whonix\\.org/"},{"host":"forums.whonix.org","redirectTo":"http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/","urlMatcher":"^https?://forums\\.whonix\\.org/"},{"host":"phabricator.whonix.org","redirectTo":"http://phabricator.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/","urlMatcher":"^https?://phabricator\\.whonix\\.org/"}],"globalEnabled":true}
1 Like
According to @mig5
this issue should now be fixed as seen above. On an own note I managed to make https everywhere redirect from https://whonix.org to the v3 onion address. I learnt 2 things today: To do just that and that the longer onion addresses are called v3 
Adding something as an edit after I got the onebox forum achievement: Ironically I got the onebox achievement and at the same time the link did not expand into the usual stuff that one gets when one posts a clearnet link(I’ve used discourse Forums before)
Regarding HTTPS EVERYWHERE >>
With further elaboration I’ve discovered an upstream bug that affects both this browser’s https everywhere Version: 2018.9.19 add-on(inside Whonix-Workstation-14.0.0.7.4) and in the regular Tor Browser(also Version: 2018.9.19). Hitting Reset to Defaults leads to nothing changing from all advanced rules I’ve added…not even after restarting Tor Browser. I haven’t yet tried restarting the browser inside Whonix-Workstation though)
1 Like
Due to above news, our method of forcing onion on the project website will break.
Removed the ‘https-everywhere’ part since it’s deprecated.
1 Like