Long Wiki Edits Thread

While clean-up & dusting out the Whonix attic is on the cards:

1. The entire page of Dev/Old Changelog should be moved back to the dev backroom where it belongs and moved out of the Whonix Overview section IMO.

It is strictly dev interest only, old and out-of-date for recent developments, badly needs editing, and is probably only read very occasionally.

A leaner, focused ToC page increases readibility and reduces overall complaints e.g. as noticed with various forum topics decreasing in frequency as documentation became clearer or was created to fill a void.

2. There is also a need to manage the size of documentation “chunks” in the most extreme cases. Right now, some of those Tor pages could easily be collapsed into a single page, while the Security etc pages could have a entire section of their own on the main TOC.

The Security Guide in particular has a logical structure to break down into 5 or 6 chunks (pages) e.g. security by platform/VM (host, Whonix-WS, Whonix-GW, Qubes-Whonix) and a couple of other miscellaneous bits (operating system / software package updates, repositories, etc.) that would nicely round out a section on the main TOC, called “Basic Security Guide”.

The same method can be repeated for “Advanced Security Guide”, which is far too long. Now we have a “collapsible” ToC, the impact is negligible, but the improvement will be great.


Please add.

1 Like

Add zerofree -> fixed.

TODO reminder:

  • Remove Dev/Old Changelog from ToC
  • Note no leak of MAC address with that Tor Browser attack
  • Split history page from ancient Whonix version info OR link only to History page (TBD) and remove from ToC
  • Full screen fingerprinting issue
  • Guard fingerprint note
  • Minor template nits
  • Add some (more) shit to Email section
  • Clean up the remainder of the Whonix Overview section harshly
  • Cleave Security Guide into chunks
  • Add remainder of Whonix 14 changes to release notes (from link)
  • Merge some Tor pages in Whonix Overview section
  • Finish Whonix Comparison nit edits (I’ll just note Qubes TorVM is deprecated and kept for comparison purposes only - easiest solution)

Note to self: should use this link Whonix ™ for VirtualBox - Testers Only Version more now that I created it a while ago. Just created and then didn’t put it into use.

There is now a separate wiki page for stable and testers-only VirtualBox version.

Should not share the link https://download.whonix.org as it clearly says:

This page is intended for developers only!
Regular users should vist https://www.whonix.org/download/ instead.

My mistake.

I guess we need the same for KVM. @HulaHoop

1 Like

Requests by Patrick

  • Add wiki Libre Software
    development vs development inside a company works → wiki faq
  • Add to use curl in Whonix users should use curl.anondist-orig → Dev/anon-ws-disable-stacked-tor

Would like to complete at some point

Working on Libre development for 2 week or so. Unfortunately I’ve been having some creative difficulties. Writers block? I’m close to finishing and normally I would say I’ll have it done latter on today. However, its most likely going to take me a few more days with the way progress is going. As soon as this it finished (all edits are complete and pushed to wiki) I should be able to complete my backlog rather quickly.

I apologize for the delay


I look forward to seeing it. :slight_smile:

-> All done, except:

  • Add some (more) stuff to Email section
  • Clean up the remainder of the Whonix Overview section harshly (Comparison & Authorship pages only left)
  • Cleave Security Guide into chunks
  • Add remainder of Whonix 14 changes to release notes (from link)

Also needed:

  • Any Qubes R4 adjustments for DisposableVMs (sounds like 0brand kinda stuff :wink: )



Cleaned up Template:TorBrowser Proxy Configuration - Whonix based on what we did with custom Tor Browser lately and removed Foxyproxy references.

Needs testing but should work.


Does this still apply…?

Due to a bug in Tor Browser, [1] extra steps are required to use proxies.


Note: This action will break both the Stream Isolation for Tor Browser and Tor Browser’s tab isolation by socks user name. This worsens the web fingerprint and causes the user to be pseudonymous, rather than anonymous. To mitigate these risks, consider using More than one Tor Browser in Whonix, or better yet, Multiple Whonix-Workstations.

So the fact that we allow other proxies at all would alter the fingerprint. Stream isolation isn’t effective because all connections are headed to the same proxy IP and so use the same circuit.

The part about SOCKS proxies isn’t relevant since we don’t endorse them anyhow.

Based on:


Tor hidden service

An experimental Tor OnionBalance hidden service is running as hkp://jirk5u4osbsr34t5.onion consisting of the servers marked with Tor support in the status list as backend.

And TorBirdy also using it:


Use the recommended proxy settings for TorBirdy (Tor)

When this option is selected, TorBirdy will change the proxy settings of Thunderbird to configure it to use the Tor network. The settings this options changes are:

SOCKS host:
SOCKS port: 9150
Keyserver: hkp://jirk5u4osbsr34t5.onion 

This is the default option when TorBirdy is installed.

We should probably point any wiki keyserver steps (i.e. key search and uploading keys) to default to the hkp://jirk5u4osbsr34t5.onion instead?

1 Like

Hmm looks like we should put this straight into the wiki somewhere appropriate, since we don’t have proper instructions right now on doing this procedure properly? (And will apply somewhat to future versions of Qubes-Whonix).


Manually install Whonix 14 templates

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-core-admin-addon-whonix

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw-14
qvm-create sys-whonix-14 --class AppVM --template whonix-gw-14 --label black
qvm-prefs sys-whonix-14 provides_network True
qvm-tags whonix-gw-14 a whonix-updatevm

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-ws-14
qvm-features whonix-ws-14 whonix-ws 1
qvm-create whonix-ws-dvm-14 --class AppVM --template whonix-ws-14 --label green
qvm-features whonix-ws-dvm-14 appmenus-dispvm 1
qvm-prefs whonix-ws-dvm-14 template_for_dispvms true
qvm-prefs whonix-ws-dvm-14 netvm sys-whonix-14
qvm-prefs whonix-ws-dvm-14 default_dispvm whonix-ws-dvm-14
qvm-tags whonix-ws-14 a whonix-updatevm

To use the new sys-whonix-14 for your UpdateVM, perform the following steps:

qubes-prefs updatevm sys-whonix-14

Then, edit /etc/qubes-rpc/policy/qubes.UpdatesProxy and modify the top lines:

$type:TemplateVM $default allow,target=sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix

to become:

$type:TemplateVM $default allow,target=sys-whonix-14
$tag:whonix-updatevm $default allow,target=sys-whonix-14

1 Like

Stream Isolation

Done! Please let me know if any changes need to be made. Maybe a little to long?

@torjunkie Since most if not all of my wiki contribs require edits. Would it make more sense for you to make edits in place i.e just make edits to my post? I don’t mind and this would cut down on (sometimes large) semi-duplicate posts. Plus the edit history is still available.

BTW thanks for helping out with my edit backlog :slight_smile:

Libre Software Development VS. Development in a Company

The method used to development of Libre/free software can vary greatly between projects and factors such as software type and design goals of the project play an important roll when deciding which methodology to use. When developing proprietary software a more tradition method is typically used which used a centralized approach. In this model all aspects of the project are tightly managed and participants are given clearly defined rolls with in the project. Only a select few developers have access to the source code and its not uncommon to have many participants dedicated to core development, project management, implementation and bug tracking.

In stark contrast is the Libre[1] model which uses a decentralized style encouraging the users themselves to become involved in the development of the project. In this model participants are loosely managed and the source code is publicly available. This model solves many of the issues faced with closed-source development by integrating users into the developmental process. Since Libre users have the freedom to use and improve the software any way they like[ref]Free software - Wikipedia, they make ideal candidates to also assume the role of a “developer” of the project.

[blockquote]The terms user and developer here refer to someone’s relationship to the open source software project in question, not to her identity in the world at large.

For example, if the open source project is a Javascript library intended for use in web development, and someone is using the library as part of her work building web sites, then she is a “user” of the library (even though professionally her title might be “software developer”). But if she starts contributing bugfixes and enhancements back upstream[2] – that is, back into the project – then, to the extent that she becomes involved in the project’s maintenance, she is also a “developer” of the project[ref]https://producingoss.com/en/getting-started.html[ref] [end/blockquote].

The relationship between users and developers can be very porous: every user is a potential developer. This principle is apparent in the Libre developmental model.

  • Users should be treated as co-developers - Users are treated like co-developers. As such they should have access to the source code of the software. Furthermore, users are encouraged to contribute additional code , bug reports, bug patches etc. By having more co-developers, the rate in which bugs are found and fixed increases substantially. Note that some users have advanced programming skills, and furthermore, each user’s machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug. This in turn allows the software to evolve at a quicker rate. This concept is termed as Linus’ Law[3] which states:

    [blockquote]“Given enough eyeballs all bugs are shallow.”[/blockquote]

  • Early releases - Since many volunteers are attracted to help develop the software based on the early release. This first version should be released as early as possible. This increases the chances of finding co-developers.

    At least two versions of software should be available

      • Stable version - This version has fewer features than the developmental version but has been thoroughly tested and most identified bugs have been fixed.
      • Developmental version - For users that desire the use of the latest features not found in the stable version. Since this version has not been thoroughly tested, users must being willing to accept the risk of using a version that does not yet have all bugs patched. users can act as co-developers, providing bug reports and submitting bug patches for the developmental version.
  • Use a highly modular structure - The structure of the software should be modular allowing for parallel development on independent interchangeable components.

  • Frequent code integration - Code changes should be merged into a shared code base as often as possible to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds[4] where integration is done automatically on a daily basis.

  • Dynamic decisions making structure - There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors.

Development in a Company
Developing Libre/free software can not not be accomplished using a more traditional method. With a decentralize approach participants have much more flexibility in the developmental process which allows the software to be developed according to technical guidelines. Although this allows for companies to adapt according to different developmental needs. There are elements that can influence the overall outcome of software.

Third Party Software

For companies that only use software that is developed from within there company, the design goals which users expect can be met with less difficulty. However, this may not be the case for companies that also use software developed by other Libre/free companies. This software is developed according to the design goals of the third party project which may run counter to that of the company that uses the software. This applies not only to packages integrated into the software but also to the standalone software that may be used to support development. Changes to third party software can be time consuming and costly and smaller companies may not not have the necessary resources.

This simple illustration shows third party software used by Whonix. Note that some of the third party software also uses packages from other 3rd party project. Many of these companies do not share the same design goals as Whonix (advanced security and anonymity).

   Firefox Web Browser --- Tor Browser ---                            --- Phabricator (bug/issue tracker)
                                          \                          /
                                           Whonix ---> Infrastructure --- MediaWiki
                                          /                          \
                             Debian OS ---                            --- Discource (forum software)
                             /                                                     \  
   Many software packages ---                                                       --- Google search engine 

Company Size
The size of the company has a significant impact on development. Although Libre companies use the same methodology in development, the developmental practices used to achieve these goals is difference across companies of different sizes.

Large Companies

Many large companies employ many full-time employees and may receive contributions from hundreds[ref]The Linux kernel has about 200-250 companies on average per release contributing patches[/ref] of companies which use and depend upon the software, as well as hobbyist and research developers. Many of these companies also integrate third party packages into their software. If design changes are needed in this software the resources are available to either assign an employee to develop, test and submit a patch, or if necessary sponsor the third party company to make the desired changes.

Small Companies

Since small companies have limited resources they do not have full-time employees akin to larger companies (if they have them at all). Its not uncommon for these companies to have a 1 or possibly 2 core developers along with a small number of community members that make contributions towards development. Quite often, due to limited resources these companies must remain focused on core development which leaves less time to develop new features. This in turn prevents developers from presenting users with a unified experience[11] when using their software.

Making Changes to a Third Party Software

Its common for companies to use third party packages in their infrastructure and also integrated into their software. Although they may provide many benefits to the company, they are not always developed with identical design goals. This can lead to software not functioning as a user expects or may even break other packages. There are several options if changes are wanted in the third party software all of which require time and/or resources

  • Polity ask the company to make the changes

  • Submit a Patch that makes sense from their point of view

  • Fork the software and add your own patches

  • Use software from an alternate third party project

The methods used to change software is identical whether the request is from a large company or collaborator from a small community. When requesting changes try look at the software from the perspective of the third party project. The developers are more likely to accept the changes if they also benefit the design goals of the project. If significant workload is added with little benefit to the project, the changes would likely be rejected. Many project have instructions specifying how to submit patches on their web site. Whonix Patches Welcome[12]

The last option is to fork the software and add your own patch. Since maintaining an additional software package could increase the workload substantially. Forking software is usually not an option for small companies with little resources. The better option would be to submit a patch so all users of the software would benefit, not just users of software from one company.


[1] Free software - Wikipedia

[2] Upstream (software development) - Wikipedia

[3] Linus's law - Wikipedia

[4] Daily build - Wikipedia

[5] Mailing list - Wikipedia

[6] Internet forum - Wikipedia

[7] https://en.wikipedia.org/wiki/Git_(software)

[8] Mercurial - Wikipedia

[9] https://www.discourse.org/

[10] User experience - Wikipedia

1 Like

My plan is to complete:

to use curl in Whonix users should use curl.anondist-orig

Then start working on:

Qubes R4 adjustments for DisposableVMs

1 Like

It looks as though “Libre Software Development VS. Development in a Company” chapter has an identity crisis. The first section is “This is the model, this is what you need to develop Libre” when is should be “LIbre model co-developer concept”.

  • “Infrastructure” and “Developmental Version” sections can be removed.
  • One of the paragraphs can be removed
  • Other edits?

Second section “Development in a Company” needs to be shortened.

  • Combing “Company Size” (large and small) makes sense. Remove some content.
  • Try to simplify the section

I’ll have the edits completed later on today.

1 Like

Not sure where we discussed this. Just to make sure: This is not a wiki wide thing. Only when they want curl without stream isolation.

1 Like

“Libre Software Development VS. Development in a Company” Chapter

Has been updated.

I see where I can condense subheadings

“Third Party Software” and " Making Changes to a Third Party Software" :slight_smile:

Here Unable to update Whonix - #10 by Patrick

1 Like

Not sure centralized vs decentralized is a useful concept here. For example, onionshare is centralized in Micah. And Whonix is centralized in me. Hard to truly decentralize it. I haven’t seen projects where it truely doesn’t matter much if the main developer vanishes.

Libre Software Development VS. Development in a Company

Maybe better compare Windows (same of Mac OS) and Linux distributions?

Important differences:

  • chain of command
  • authority to issue directives
  • possibility to deliver a unified experience (Windows) (CEO can issue directives to the developers of internet explorer to make it fit into the overall vision, guaranteed execution, fire on non-compliance)
  • patchwork rug (linux distributions can only pick what’s available, need to ask/contribute nicely while taking the perspective of the third party project)
  • funding
  • popularity

Maybe a comparison table?

This fits better at the bottom of the text perhaps to justify what’s the point of FLOSS if it’s such as patchwork rug.
(Related: Why Whonix ™ will always be Free as in Price as well as in Freedom)

The main desire of mine here was to explain to users who come from a nice unified usability experience. Like iPhone - you can complain about many things, but on the points of usability and a unified experience [no patchwork rug], you can’t complain. What I mean, lots of people come from an iPhone experience and then are going to demand the same from FLOSS. They’re entitled to their opinion and demand, but it makes sense to explain why things are as is.

Therefore this also doesn’t fit.

We have that here has The User Co-developer Concept .
Free Support for Whonix ™

Something like this.


I am sure, prorietary software development isn’t a piece of cake either but we don’t have to explain why that is.

companies: less about company vs non-company. There are also companies working on Open Source. It’s about proprietary (chain of command based development) vs libre distributions (patchwork rug).

Showing some examples is really good.

Companies refers to proprietary software, I guess. In these cases, they often don’t get the source code of third party software. So they can’t submit patches. Neither legal (nor feasible) to fork.


  • targeted at users expecting iPhone experience but getting linux distribution patchwork
  • rehash the forum posts I wrote before?
  • not so much a detail analysis of development inside a company vs open source development style (except: distribution maintainers can only ask nicely, even phrasing a nice request that gets understood is work)
1 Like