Maintainer for Whonix Welcome Page


Are you still looking for a maintainer for the Whonix Welcome Page? If not, I would volunteer to maintain that component.

Some ideas I had:

  • Make a build script to provide easy translation support (text and links to translated versions of wiki pages)
  • Update the design to look more like the Whonix homepage
  • Add .onion and offline links if available so the user has the choice if he wants to use HTTPS or .onion URLs or an offline version.
  • Maybe also a slightly different version for the regular Firefox (formerly Iceweasel) browser with a warning that suggests the use of the Tor Browser? (think I remember such a warning when starting Iceweasel, was it removed? or has it stopped working?)


Good day,

That would be great and very nice off you. What kind of approach would you take in regards to translation? Fully replace the current plugin with something custom?

Have a nice day,



I was thinking about just replacing placeholders and have a list of replacements for each language and fall back to English if a string is missing. This is a very simple solution but I think it’s the easiest because there are just a few strings. Maybe GNU gettext if a simple list of replacements isn’t enough.

What current plugin? I thought those where just static HTML files right now. (for clarity https://github.com/Whonix/whonix-welcome-page)


https://github.com/Whonix/whonix-welcome-page - inside Whonix-Workstation, Tor Browser start page.

https://github.com/Whonix/Whonix-Website - https://www.whonix.org - unrelated.



Probably broke because of the folder change by Debian. https://github.com/Whonix/anon-iceweasel-warning/tree/master/etc/iceweasel is now /etc/firefox-esr. Yes, please fix and duplicate that file (in case one day they go back to calling it iceweasel).

Depends. Too many choices ruin usability. Onions seem stable, so why https.

How would you implement an offline version?

Which build script?

Well, we don’t have much translations in place yet.

Unless someone things it’s a bad idea for some reason… Why not.


  • don’t fetch remote resources
  • don’t use javascript

That’s for security. And possibly also for privacy and fingerprint.


A script that downloads parts of (or the entire) wiki, build an index and makes some changes for offline use (I still have to read through the Offline Documentation Discussion, though it seems that there are some concerns with this approach)

A script that would have to be written. It would take a template and translations and produce multiple HTML files (one for each language). Maybe “build script” was the wrong term?


The security aspect of offline documentation is the hard part. Especially post Offline Documentation Discussion breaks it.

I don’t think it’s a good idea to download from whonix.org during the package build. It’s a remote, live, changing location. Not a source file.

Would be a break of the security model. I consider whonix.org a binary format. All Non-Qubes-Whonix VM images for now have been produced locally from source code on my developer hardware. (Except for binary Debian packages which are installed inside VM images as is from Debian repository.) Adding a binary file (the pdf) that I generated from the Whonix web server would break that model.

Since it’s a changing location, it would also break (future) reproducible builds.

The offline documentation would have to be created from source files.

But even https://github.com/Whonix/whonix-wiki-backup is not vetted. It’s auto generated on whonix.org server using git-mediawiki as backup tool. A breach of either whonix.org or github.com could lead to malicious content in these unvetted, auto generated source files and once a user clicks these, they could get compromised.

I think for offline documentation we first need to fix the documentation security model. That is, documentation is edited as source files on github. Whonix developers then keep merging and signing changes for being non-malicious locally. These source files would be used to create the website html. Not the other way around we are currently doing it. It might mean to move away from mediawiki. A lot work.


Agreed. Before the offline implementation by @Hexagon , let’s use onions instead!

Here is my pull request:

Notice the changes I made also claims that:

<p>The official Whonix website is located at: <a href="http://www.kkkkkkkkkk63ava6.onion" target="_blank" rel="noreferrer">Whonix.org</a></p>

I am not sure if .onion can be called the official Whonix website, or it only servers as a onion mirror. So feel free to change it if I am wrong. :wink:

Btw, when it comes to using Whonix onion website, a more throughout and reliable way to do so is:


Is it a good idea to ship a Tor Browser with WhonixOnion.xml rules? If so, should we enable the rules by default?

This patch may change the fingerprint of the Tor Browser but does it matter?

I can help to do further work if it is considered as a good idea!


Thanks, merged!

Tor Browser changes are hard to apply consistently. Since it’s not packaged, so very messy. And any modification could break it’s internal updater. So probably not a good idea to do this on behalf of the user. If anyone should add such changes, it’s Tor Project upstream.

Also, we need to slow down on Whonix features after Whonix 14 (which is already long behind schedule). tor-connection-wizard will be the last major enhancement since it was already agreed to take it and since you’re working on it already.

Next, the maintenance, package build and release process burden needs to be considerably reduced. Automated package builds, automated image builds, build documentation, upgrade sanity tests from version state X, Y, Z to new etc.



Thank you for your answer and instructions, Patrick!

It makes sense. Without improvement on the efficiency and working force, the difficulty of maintenance may broke Whonix.

I am trying to understand the background and details of the problem to see what work is expected to be done.