Long Wiki Edits Thread

re Tox:

I removed the su for becoming root in my previous edit. To be allied with most other places in the wiki where we consistently use sudo. I open to reconsider this. There are some commands that should not be run as root.

  • wget
  • gpg --keyid-format long --with-fingerprint Release.key

(So currently it’s broken since never su nor sudo.)

I don’t know if the rest gets simpler by using su and exit rather than using sudo everywhere. You tell me.

1 Like

Right - good point. Tox -> Fixed.

Removed root instruction and changed these things to sudo (since I checked that it’s required permission-wise):

  • copy .gpg pubkey to /etc/apt
  • create a new qtox.list
  • update package lists
  • install qTox

These don’t require sudo permissions (I checked):

  • wget
  • checking gpg fingerprint
  • converting the Tox signing key to a keyring to be used by apt

Contribution Page

I fixed that up. The only bit I didn’t - I think you told me not to before - was this part:

Donations tax-deducible by default are not tax-deductible because Whonix has no legal structure for that. If you would like to make a tax-deducible donation, we can make that work as well, please get in contact.

Unreadable first line and awkward second line. I’d really suggest something like:

The Whonix legal structure does not provide for donations that are normally tax-deductable by default. If you would like to make a tax-deductable donation, please get in contact so we can make that work for you.

Formatting in General

Yes, in the long term (post months of editing wiki pages for basic grammar and readability), there needs to be a conscious effort to standardize formatting across the wiki and improve the overall presentation. I’m trying to do many of these as I go along:

  • Root vs sudo
  • Consistency in the size of text in various areas
  • Creating other templates for commonly used steps
  • Shifting around text that is repeated in multiple areas (the Security Guide, Advanced Security Guide, Computer Security Education and some others are the worst offenders - particularly the beginning chapters of the wiki which need to be merged / deleted)
  • Shifting text around to actually match the level of difficulty for various security guides
  • Rationalizing the overall Table of Contents and the order in which things appear. It’s a dog’s breakfast right now.
  • Use of sub-chapter headings to break up huge blocks of text that are basically unreadable now
  • Consistency in mediawiki heading / sub-heading formatting
  • Consistency in mediawiki forms used e.g. pre vs code and a million others
  • Consistency in the amount of text allocated to its own heading / sub-heading e.g. sometimes three words, sometimes a whole page
  • More appropriate use of paragraphs. It is wildly inconsistent now which affects readability. Sometimes it is one line, sometimes it is a huge block of text
  • Greater use of tables to summarize issues that have a lot of specific points to consider
  • Updated screenshots since many in the wiki are ancient / outdated. Screenshots for many topics would make the wiki much more presentable and improve user understanding of various issues
  • Consistency re: accepted English standards e.g.
    – Capitalization
    – Bullet point style
    – British English vs American English
    – Bold vs italic text vs underlined text etc
    – Colons vs semi-colons (and capitalization following colons; we’re not consistent)
    – Appropriate use of hyphenated text
    – Passive vs active voice in writing style (the active voice is generally better for readability and clarity)
    – Use of pronouns - I / you / your / we / he / she / us /mine etc are generally best avoided. It’s better to use “the” where possible and not possessive pronouns and other forms
    – Removing any slang / common forms of English that pop up here and there
    – Standardization of acronyms (e.g. DispVM vs DisposableVM, and a million others)
    – Avoiding shortened forms of words for clarity e.g. distros vs distributions
    – A shit load of others that I can’t remember right now
1 Like

re: https://www.whonix.org/wiki/Template:Donate

Right. The previous sentence was obviously broken. Added your fixed sentence. I don’t know why we used “by default”. Simplified to:

Donations are not tax-dedutable. If you would like to make a tax-deductable donation, please get in contact so we can make that work for you.

What do you think?

Great points!

Right, I guess sudo is easier.

Right, such as for third party repositories, gpg fingerprint verification, signing key adding. As far that is possible. For example it differs gpg key download over clearnet and wget vs https scurl.

I guess CodeSelect everywhere, except for maybe <pre> for cases where it’s just for formatting, not for easy copy and paste.

1 Like

Great that we are on the same page.

That donations text looks much better now (your suggestion).

I forgot to add in the grammatical critique:

  • Avoiding run on sentences; and
  • Not overusing brackets “()” in writing. Usually it’s best to reorganize the sentence and write it outside of brackets, or footnote the issue if it is a minor point. Also, it is not normal to start a sentence with bracketed text.

There are others, but I don’t want to go crazy :wink: First things first, let’s finish the template edits - I’ll go back and look over some recent ones you’ve added, then I will methodically go through each wiki page listed in the Table of Contents for general edits.

The finer stuff can come later. But, let me add another link in the forums here for you and others on the team to add re: missing templates required. So far, based on your list:

  • Adding Third-party Repositories
  • GPG Fingerprint Verification
  • Adding Signing Keys
  • Others?
1 Like

Are you sure it is better to use


Explanation what to do:

actual command



Explanation what to do.

actual command


Most guides I saw anywhere are using . rather than :.

That’s a good point re: colon & instructions/steps.

I just made that decision on the fly. If it is a full stop/period in most computer tutorials (I’m sure you’ve read a million), then lets note to fix them all back in the ‘finer edits’ Round 2 of the wiki edits. In the meantime, I’ll just use periods instead of colons going forward.

Re - Template: Verifiable Pkgs Introduction

The Debian dpkg bug causing the installed size to be wrong by a factor of 8 has now been resolved. I footnoted that, but noted those steps are still deprecated because it is difficult to implement at this time prior to Debian Stretch etc.

Note, this editing led me to conclude ->

Do we need a Maintainer Required Warning Box template?

I know the status box template already exists, but I keep seeing the manual warning box repeated all throughout the verifiable builds templates I have been editing of late.

So the template could look something like this:

| image = [[File:Ambox_warning_pn.svg.png|40px|alt=verifiable builds warning icon]]
| text =

A dedicated [[Contribute#Maintainer|maintainer]] is required.

1 Like

Yes, created empty https://www.whonix.org/wiki/Template:Maintainer_Required.

1 Like


Changed the mbox “type =” from “critical” to “content”.

It was coming up with an error before saying “critical” is not an accepted field blah blah and not presenting properly (I think it was also based on a template “Main” that was deleted sometime in the recent past?). I’m sure you can fix it up if it’s something basic.

See mbox types here: Template:Mbox - MediaWiki

Do we need the {{ }} brackets around “Verify the virtual machine images using Linux”? It presents strangely.


There is strange formatting in this template that doesn’t present properly (broken links?) e.g.



[[{{{download_signature_link}}}|Download Whonix Signature]]



Not sure if they’re fixable, so I’ve left them for you to decide.


Spelling error & and the internet tells me it is “deductible” not “deductable” :slight_smile:


Donations are not tax-dedutable. If you would like to make a
tax-deductable donation, please get in contact so we can make that work for you.

Change →

Donations are not tax-deductible. If you would like to make a
tax-deductible donation, please get in contact so we can make that work for you.

So, I’ve done one editing round on the 236 templates. But I’ve missed a few earlier on I think e.g. build templates and some others, plus any new ones you’ve added lately.

So, I should probably go back and look through again (quickly) to cover those off and do some finer edits re: colons and a few other things, since that will be quick and easy. Here and there I’ll break up the boredom with general wiki page edits.

Once done, I propose to start editing the wiki entries in order as they appear in the ToC.

1 Like

Note in the second round of template edits, I will focus on finer grammatical points already noted above, plus:

  • Double quotation marks in most instances i.e. " " is better than ’ '. The grammar texts note that " " is more common and usually correct in most instances.
  • Use American English i.e. simplified spelling etc.
  • I think we should also standardize file path references in italics consistently e.g. this form:

Open /etc/apt/preferences.d/debian-pinning.pref in an editor with root rights.

There were some other points that I can’t remember right now, but it’ll come to me…

1 Like


Do we need the {{ }} brackets around “Verify the virtual machine images using Linux”? It presents strangely.

Yes. Please fix. I think the intention back then was to make that link
going to either VirtualBox or KVM verification instructions depending
from where the template is being referenced, i.e. from VirtualBox or KVM
wiki page. Please fix the easy or “perfect” way.

1) Re: above → Done.

(Additional edits are looking much better without pronouns and better stylistic formatting as we agreed further above.)

2) Also, shouldn’t the license page be:

Copyright (C) 2012 - 2017


If not, at a minimum there should be an additional space after the hyphen.

3) Template:FoxyProxy looks well out of date and messy.

It mentions 6 steps, but there are only 3 steps in there.

Do you want me to test FoxyProxy with Tor Browser 7.0a2 using Goldstein’s method of disabling sig verification and fix up the entry?

I think also we can lose all references to the “hardened” Tor Browser since that will die very shortly.

4) Next Tor Browser release.

I understand that the next release (?) will have FF ESR 52 applied to the Alpha series of Tor Browser (but not the normal release series). So, with e10s applied and a lot of changes, this will no doubt screw with Whonix settings in some way, shape or form.

Have you tried the nighties from The Tor Project to check general compatibility?


I’m happy to also run a test in Whonix 13 if you like. The chances of this working like a dream I think are remote (see Tor Trac issues around ESR 52 - many, many bugs, patches, fixups and strange behaviours).

5) I realize bullet points are a grammatical nightmare of their own.

Technically the rules are:

a) Bullet points don’t need the first letter of the first word to be capitalized unless the bullet points comprise a full sentence e.g.

These are okay:

  • multiple Whonix-Workstation TemplateVMs


  • Always check that the GPG timestamp makes sense.

b) But technically the following are NOT okay:

  • Multiple Whonix-Workstation TemplateVMs


  • always check that the GPG timstamp makes sense


  • Always check that the GPG timestamp makes sense

c) The other accepted method is having bullet points finish with a semi-colon, a period for the last bullet point, and using a conjunction on the second-last bullet point e.g. “and” “or” “and/or”. This is the British English style, applies in certain industry standards etc. For example, these are okay:

  • time-stamps;
  • signature verification; and
  • checking the signing key.


  • Make sure you download the Whonix-Workstation and Whonix-Gateway virtual images; and
  • Verify the images after downloading them.

d) All of these same rules apply to numbered lists

e) Many websites ignore these rules e.g. the Qubes website that capitalizes the first word and doesn’t end the bullet points in a period. Probably because it looks better.

I think we should adopt the most commonly accepted method i.e. part a). Right now we have a mix of all of the above throughout the entire wiki…

1 Like
  1. If it’s copyright under my name, then yes, can be updated.

Yes, please fix.

  1. Bigger changes to Template:FoxyProxy, i.e. method changes should be discussed in https://forums.whonix.org/t/new-version-of-tbb-no-longer-accepts-foxyproxy-plugin. Yes, please feel encouraged to work on that one.

As for disabling signature verification, we need to make sure what we are actually disabling. Installing foxyproxy from Debian repository (when apt-get already done signature verification) and then just force adding the add-on to Tor Browser would be fine. However, if we disable signature verification which then would result in no longer checking any signatures for addons installed from addons.mozilla.org, that’s not a great. Doing that temporary would be okay (if the add-on stays functional after installation).

Also GK (TBB dev) said it’s working for him.

So this could require posting on tbb-dev again with a clear concise description of steps done, expected results, actual results. Should probably draft it and write then.

In that thread, talking past each other is so simple…

  • this workaround doesn't work with the latest addon-manager version from Mozilla
  • Not sure what you mean with "latest addon-manager version from Mozilla"

…so the text must be as explicit as possible, reusing exact terms, describing actions step by step (i.e. Tor Browser → Tools → Add-ons) and whatnot.

Well, as long as it exists it’s good to have a small chapter about it somewhere.

  1. By all means, please test.

  2. Yes, please fix.

Template:Build Documentation apt-cache: Difference between revisions - Whonix has a mistake. When “can be used” is written anywhere, I am quite certain, the meaning really is “it’s a possibility, you could do that”. Writing “is used” is certainly wrong. That sentence just explains a possible setup one could do.

On Template:Control Port Filter Python Profile Add - Whonix, should we describe what the mkdir and cp commands are actually doing?

Template:Design Introduction - Whonix is nice.

  • once done, deserves an extra thread
  • I only disagree with using <pre> for quotes. The issue with pre tags is, that it’s more suited for code that should be unmodified at all cost. pre does not do line breaks. It results in a page that must be scrolled horizontally. <blockquote> is for quotes. And if we don’t like that, we still need an alternative formatting for quotes.


  • should be moved elsewhere, since where the template is used it makes little sense - Login required - Whonix
  • needs a better page name
1 Like

Other long term goals could be being more like https://simple.wikipedia.org and ELI5.


One of the key benefits of Whonix is that when a VPN connection fails, you will still have the protections provided by Tor.


One of the key benefits of Whonix is that when a VPN connection fails, protections are still afforded by the Tor process.

Do you think afforded is suitable here? And is better than provided?

Thanks for all that feedback & bulk sign-offs.

Yes, I agree with all your feedback above. I’ll fix all that up as per your directions, but am having a little break from editing, just for today. :sweat_smile:

That is really useful -> wiki/Special:WhatLinksHere/Template:Design_Introduction

I’ve been looking for something like that! Perfect.

Good luck with your live streaming thing tomorrow.



1) License wiki entry -> (Already) Fixed

2) Template:Build_Documentation_apt-cache -> Fixed

3) Template:Control_Port_Filter_Python_Profile_Add -> Fixed

Added some text there (but check if it’s right, because I know nothing about the control port filter) :slight_smile:

4) Wiki Main Page -> Fixed.

E.g. semi-colon issue and changed text slightly re: what Tor protects from, since anyone with end-to-end netflow correlation attack ability can screw over Tor users. Before, the text read like Tor is a silver bullet.

5) Security Guide -> Fixed.

A million little things. Also noted deprecation of hardened Tor browser and the Alpha series picking up ASan and Selfrando protections after April release of Tor Browser


1) Remove extra text from Template:Design_Introduction and move to a wiki thread if you create one.

How about creating an extra entry under “Miscellaneous” on the main wiki page e.g. something like “Whonix Wiki Editing Guidelines” or similar? If you do that, I’ll separate purely stylistic issues from grammatical issues.

2) Try Tor Browser nightly for Whonix compatibility (I bet it doesn’t work, but we’ll see)

3) Attempt Foxy Proxy steps and follow up with the other forum thread users to check correctness for a Wiki entry

4) Test Whonix wiki back-up script

5) Edit Bridges wiki entry for simplicity since users keep posting about it in the forums (it can be improved, particularly the output re: what the torrc file should look like)

6) Add Micah Lee’s expose of Subgraph to the Subgraph OS comparisons page

7) Keeping on head-banging the second round of wiki templates.

The horror, the horror… :wink:


OK, working my way through the Bridges stuff.

1) Re: this in Bridges section →


  1. When Whonix starts for the first time, it won’t automatically connect to the public Tor network, which is beneficial for safety reasons. Users are guided by the Whonix Setup Wizard, which is automatically started.


I’m pretty sure this only applies to non-Qubes-Whonix (?). That is, Qubes with Whonix templates installed from the installer connects first time without any prompting from memory. But I might be wrong.

If that is the case, we should note this for users who risk being harmed if identified Tor use is bad in their country i.e. they MUST config torrc first before ever trying to connect to the Tor network or running Whonix templates/AppVMs.

2) Re: http://kkkkkkkkkk63ava6.onion/wiki/Bridges#Finding_a_bridge_and_choosing_the_right_protocol

I updated it to reflect The Tor Project’s preference for obfs4 (but obfs3 is still okay). Apparently the former works more often in various regions.

Another question, at this link we have in there →


One of the check options at The Tor Project is something like:

Get an IPv6 compatible address?

I presume we should be noting that Whonix users should NOT check this option given various risks linked to IPv6 re: possible deanonymization?

I’m not even sure if it’s compatible with Whonix (I know Qubes doesn’t support it yet from memory).

1 Like

Bridges wiki entry -> Finished

Just need to check with you those 2 issues above i.e. IPv6 and truthfulness of Whonix not auto-connecting statement.

I think it’s much clearer now for the user.

1 Like