Great!
Yes, please go ahead with tox.
Done. http://kkkkkkkkkk63ava6.onion/wiki/Template:Tox → Fixed.
Re: downloading and importing Whonix-Custom-Workstation (VM Settings Easy Common template), I see on the server that the latest available Whonix version is: 9 for this customized build.
Since we are pushing Whonix 14 in a few months, perhaps I should just mark that part of the template as “deprecated”?
Unless people can somehow install it and do an upgrade bumping Whonix up several versions at once to the current 13 version (which I doubt).
1 Like
Some more edits to Template:Tox - Whonix. Please check.
This is expected. Should be explained why it’s not updated.
1 Like
Thanks! You’re schooling me on GPG (good to know this stuff).
Tox Template:
- Added a reference for list of GPG fingerprints used by qTox developers for users to check
- Removed a few “sudo” references, since everything is run in root
- Removed ugly bullet point effect from the footnotes
- Added one footnote re: updating the Tox apt repository to “Stretch” when Whonix gets upgraded
- Tested these instructions in a TemplateVM, created the AppVM, and ran qTox → worked perfectly!
Cheers
1 Like
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 
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
colon
Explanation what to do:
<pre>
actual command
</pre>
vs
dot
Explanation what to do.
<pre>
actual command
</pre>
?
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:
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px|alt=verifiable builds warning icon]]
| text =
Warning:
A dedicated [[Contribute#Maintainer|maintainer]] is required.
}}
1 Like
Yes, created empty https://www.whonix.org/wiki/Template:Maintainer_Required.
1 Like
Template:Verify_the_Whonix_images
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.
Template:Verify_the_virtual_machine_images_using_Linux
There is strange formatting in this template that doesn’t present properly (broken links?) e.g.
({{{file_extension}}})
And
[[{{{download_signature_link}}}|Download Whonix Signature]]
And
{{{signature_notation_gw}}}
Not sure if they’re fixable, so I’ve left them for you to decide.
Template:Donate
Spelling error & and the internet tells me it is “deductible” not “deductable” 
Original:
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
torjunkie:
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?
https://people.torproject.org/~linus/builds/
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
Or
- Always check that the GPG timestamp makes sense.
b) But technically the following are NOT okay:
- Multiple Whonix-Workstation TemplateVMs
Or
- always check that the GPG timstamp makes sense
Or
- 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.
Or
- 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
- If it’s copyright under my name, then yes, can be updated.
Yes, please fix.
- 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 MozillaNot 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.
-
By all means, please test.
-
Yes, please fix.
Wiki History 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.
Minor:
- 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.
old
One of the key benefits of Whonix is that when a VPN connection fails, you will still have the protections provided by Tor.
new
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?