usability, popularity vs security, Freedom Software purism

Can you use specific examples here of shortcomings we have?

I think the Tor Project approach of doing whatever security enhancements are needed behind the scenes that don’t interfere with usability, while leaving options that can impact usability like NoScript enabled by default is the right way. Advanced users can always toggle NoScript to disable JS everywhere because they know better, while those who don’t can churn along and use the Browser anyway giving a large set of anonymity to everyone else though they are inadequate users.



First I want to say that I think Whonix, at this point of time, is at a very good place. Whonix 15 is mostly ready ahead of time. Hardened Debian project is underway. That’s great.

But, it faces the risk of having its current resources drained by wrong focus, that was not properly thought out, and that will be unsustainable for a small project. Moreover, choices made due to this focus, may compromise security / anonymity levels.

Specifically, the apparent desire to attract more lay users.
Yes, Whonix wants to protect as many people as possible, that’s commendable.
But do the people here really understand, what it means to cater for a much larger circle, of those significantly less technically skilled than the current average Whonix user?

Do you think Windows users that cannot even figure out how to handle VirtualBox VMs (if they did, no need for an installer) will accept your “Unsupported” or “Free Support Principle” pages?

Do you seek to attract them, then explain to them that you are a small project that can’t really provide the support, or that they should not expect the same user experience they are used to get with other OSs?

How does this wish to expand user base go together with the dislike of “many support tickets”, or with the thoughts of Patrick from last year to tone down Whonix into a research project?

Do you want those users or you don’t? decide.

Do you think users who use the Windows installer won’t not need to, at some point, change VM settings in Virtual Box, for example to increase memory? they will, and this attempt to dumb things down to a single exe will work (if it does at all) for a very limited amount of time. Then you will again get the support tickets you dislike so much. I say this installer is not doing any good at all. If one wants to use Whonix one must have basic capabilities to handle the virtualizer. There’s no way around it.

If you shift the focus to more lay users you should provide the level of support adequate to those lay users. Or waste many people’s time.

Whonix will have many more trivial support tickets, about Tor, about linux, about VirtualBox, about anything, doesn’t matter how many more pages or guides you add to the wiki.

But why should I care at all?

If Whonix project insists to exhaust itself, misguidedly in my view, why should I speak up?
Becuase I think this will inevitalby lead to relaxing standards and hurting all user base. And already is the case to some extent.
When you try to minimize support tickets by providing more usability on expense of security, that increases the risks to everyone.

Advanced users making adjustments by themselves? sure, it’s possible. But those adjustments aren’t done once. Main benefit to a VM is that you use it for what you need. This hardening will need to be manually done again and again and again. Forget once, continue to use Whonix as you’re used to, you may be vulnerable. Essentially you ship a less secure product that needs to continuously be hardened.

And we cannot ignore the reality here in which developers are not isolated from trivial support and forum activity. I don’t see how more lay users focus will not hurt the chances to further increase Whonix security even on the issues unrelated to usability.

Examples: kernel hardening, blacklisting / whitelisting applications firewall on the gateway, restrict workstation from finding information about host, providing forum that does not require JS, and more. There is no shortage to improvements to be made.

What about shipping a hardened version? no resources. But they exist for Windows installer or for fancy icons support?

Regarding the comparison to Tor project approach:
The two project are different in the level of security they aim to provide or what they ask users to do.
Tor project is OK with client seeing full onion circuit. Whonix isn’t.
Tor project is OK allowing insecure features of Tor Control Protocol to other programs. Whonix isn’t.
Tor project doesn’t try to convert users from Windows to Linux. Whonix apparently does (one the main reasons why Windows is supported at all. Becuase they “may become” linux users).
Consequentially, stricter settings should exists in Whonix. People don’t come to Whonix to get the same standards!

I find it very strange that a Whonix user will go all the way to use a virtualizer and VMs and then leave the door wide open to JS fingerprinting and exploits by any site whatsoever.
It makes no sense at all.
The common answer here to this issue is “we don’t want more support tickets”.
Well. I WANT to see this kind of support tickets. And the answer to this kind of ticket will be: “It makes things more secure. Don’t like it? here’s how you easily turn it off”. That’s a GOOD answer.
In fact I have seen many support tickets asking why the settings are not stricter, or generally posts concerned about JS being required. Then the answer is, “Yes it’s more secure to not use JS (and documented widely in the wiki), but we don’t want confused users posting support tickets asking about it”. That is a BAD answer. Do NOT do the opposite of what you recommend.

Even if your dislike to support tickets is somehow a good reason, shipping Whonix with less secure defaults does by itself generate those dreaded tickets anyway.

To summarize:

  • More focus on lay users requires much higher level of support that Whonix can’t provide.
  • It may lead to resources being drained in an impossible task, instead of further development and increase levels of security and anonymity.
  • It will and already does lead to lower security standard being shipped.

Very interesting discussion.

Thanks @xariv for all the good points you make.

But in my opinion you are overdramatizing things. While it’s surely very important to have a clear focus on what to work on given the scarce skilled developer resources at disposal, I fail to see where the Whonix project is currently at risk of shipping a “lower security standard” as you said. Could you provide some concrete examples of current lowered security standards?

I don’t see how Whonix as it is designed (and has been designed since the beginning as I understand it) would not address the needs of the “layman”, and how that would be a security problem. It is my understanding that on the contrary it can provide a solution for both non-technical and advanced computer users.

The way Whonix works is that it provides a fail-proof system out-of-the box, that prevents the host’s IP to be leaked to a potential attacker. If the user wants, he can dig deeper and try to run SSH/VPN tunnels, change any settings, install additional software, etc., at his own risk.

The Workstation, shipped with a user-friendly GUI (even more so since XFCE), allows users of any skills level to easily interact with it and address their particular needs, be it super complicated advanced settings, or just browsing anonymously Wikipedia…

Whonix has always be beginners-friendly. The only skill that you need is installing VirtualBox and importing the .ova files. And there you go, IP leak prevention out-of-the-box.

Then we try to convey the idea to the users that the journey is merely beginning, and we encourage them to read up on anonymity and computer security that we cover extensively on our Wiki, one of the most advanced resource on the matter that exists, although it probably needs some refreshing.

But to my knowledge, there is nothing in Whonix that should prevent beginners to use it out-of-the-box.

Take my case for example: I am not a computer specialist, have been using Whonix since more or less three years now, I had no previous experience with Linux and/or virtualization. Setting up and using it wasn’t complicated at all. The difficult part began when I tried to understand the inner workings, and documented myself on Tor and anonymity. But my initial ignorance didn’t prevent me from using Whonix. And I know personally people who use it without any knowledge on Linux systems or anonymity.

On the topic of focusing development efforts, from where I see it we are doing fine: Whonix has been ported to Buster before it has even been officially released.


Hope you don’t mind me saying, but most of your reply reads like a marketing PR or intro to Whonix written for someone who never seen it. Let’s stay on point.

Jail time is serious enough I think. Some Whonix users are probably security enthusiasts but others need this kind of solution to survive or keep their freedom. So I don’t think I over dramatize anything. Read closely, adversaries will use tiny leaks of information, utilize any mistakes and put everything together over weeks or months. It doesn’t take much.

This is really not a joke for many users.

Of course. Some been mentioned here by @micky and others appear in other threads throughout the wiki. Many already discussed by developers with decisions made to keep the current state as it is. A partial list:

  • Tor Browser within Whonix includes the lowest safety level possible by default.
  • The default clipboard sharing is Whonix VMs is the worst safety-wise (bi-directional sharing).
  • The speakers in Whonix VMs are enabled by default, allowing malware to leak information to external infected devices.
  • There is no mechanism in Whonix to whitelist applications (exists in Qubes). Suggestions to implement this as well as other mitigations of malware was reject due to lack of resources.
  • Whonix forums, essentially the only realistic option to get support, require Javascript and in some cases lower security settings in Tor Browser.

Cool. In this case why do we need to spend maintainers’ resources in writing a Linux primer? why do we need to spend developers’ resources on working on Windows Installer? have you seen the following recent activity? so many suggestions get the reply “no resources”.

A complex topic with no doubt in Whonix. A very easy topic elsewhere:

  1. Install Tor browser.
  2. Sign up for VPN.
  3. Install VPN app on host.

Bang! you got VPN before Tor setting. All done with clicks! No editing of configuration files! No creating users or changing permissions! Not breaking stream isolation (coz they never had it).

This setting is actually a requirement for many Tor users (whether it’s good for them or not it’s another question) - I can promise you the vast majority of them can do the above as I described and will not get into doing the setting in Whonix. Yes we can improve education (wiki) but we should admit that Whonix isn’t for everybody.

Great! so let’s ditch the plans to work on windows installer / linux guide etc. and get back to the real tasks!

That’s exactly what I wrote in my first paragraph.

No, just some enthusiastic writing from an enthusiastic user :slight_smile: But you are right, let’s stay on point.

Agreed. But then if we are talking about potential jail time, then additional measures are to be taken, such as encrypted USB disks, using bridges to connect to Tor, maybe connecting to public Wifi spots (although might not be a good idea in certain circumstances).

What I mean is that if it really is a question of life or death you surely need to be very up-to-date with OPSEC and anonymity topics, merely installing Whonix on Windows and expecting it to cover all your needs out of the box is unrealistic.

Thanks for the concrete examples.

  • Tor Browser: good point, maybe open a new topic (don’t know if it has been already discussed recently or not)?

  • The default clipboard sharing is Whonix VMs is the worst safety-wise (bi-directional sharing) -> can be disabled very easily. In KVM, disabled by default.

  • The speakers in Whonix VMs are enabled by default, allowing malware to leak information to external infected devices -> it’s being currently discussed, so nothing definitive here as I understand:

Valid points. If you have the skills and time, I am sure your contribution to the first point would be very valuable. As for the forums, I am afraid there is nothing we can do as long as we use discourse.

A majority of people will go for the easy path. That’s understandable and their own choice. This could also be achievable within Whonix, but it requires some commitment. But it is possible, and documented. So I think we agree it’s the user choice eventually. And yes, Whonix is probably not for everybody or lazy users, but there is nothing that inherently prevents it from being used by anybody.

Regarding resources allocation, I think it really depends on who does what. If @Patrick or other core (and skilled) developers would devote half their time to documenting file permissions in Linux, then yeah that would be pretty bad I guess :slight_smile: But if that would be me, or another regular user, that wouldn’t be a waste of resources, don’t you agree?

my bad, must have missed this!

usability, popularity vs security, Freedom Software purism is a decision on a spectrum. I don’t see much point to debate #project-philosophy.

It doesn’t come to surprise that some existing and/or advanced users capable to adjust to these usability issues will argue for their benefit.

law of triviality / bikeshed applies. More weight will be given to contributors and developers.

What mechanism are you referring to?



A list is good to have. It allows to:

  • a) contribute source code that implements (a) build parameter(s) applying these settings by default
  • b) justify a software fork of Whonix

No excuse for sub-par settings in Whonix.

Appears in wiki with reasons why not to do it.

We are discussing defaults. Also I mentioned the point of repeatedly hardening non secure settings. Please read more carefully.

I share your hopes. My replies here were after reading this thread.

Let’s keep the discussion realistic and less theoretic.

I would agree. I did however mention above the point of developers not being insulated from ongoing support and forums. Maybe good if Patrick would do it. Fact is, he doens’t.

Also discussed here at length

Similar points in

Usability issues are one point. Admittedly less serious then the second point, namely less focus on advanced security (unrelated to usability).

Certainly reasonable. I voice my opinion here. I believe the points I mentioned will improve the conditions of virtually all current Whonix users.

If we’re discussing theoretical, significantly less capable joiners, perhaps less so.

In this case I will add more items then when I notice them. Sure, if they can be added as build parameters that will be a big step forward.

I don’t see a fork of a project of this complexity as something that’s going to happen anytime soon.

Not all feature requests are created equal. Pure logic such as:

  • X takes develoment effort
  • development effort spent on X was a waste because that would have given us Y already

is invalid. It ignores the human question. It ignores the available skillset of developers. As you may have noticed, I never created original quality GUI applications but I’ve been capable to modify them. Some things are easy for me (such as this time port from stretch to buster) since I am trained in that (lintian warnings, packaging of simple things scripts, non-compiled code) but to deduce from that I could have equally easy come up from a firewall GUI utility - no.

Quote from FAQ:

By comparison, generally the architects of complex structures like buildings or hardware (and a myriad of other professions) do not explain any technical details for free to the general public.

Volunteer contributions to Whonix ™ are most welcome. All proposed patches are carefully reviewed and merged if appropriate. Volunteers with the requisite coding ability should refer to the current backlog of open Whonix ™ issues and consult with developers before undertaking any significant body of work.

Often, proposed improvements or fixes to the Whonix ™ platform are awaiting implementation due to differing developer priorities, limited human resources and/or the inordinate amount of time required to develop a particular feature or solution. In a minority of cases, the Whonix ™ team is unsure how to resolve a bug or implement a specific change / feature. [70]

It is generally unhelpful to debate the priorities laid out in the future Whonix ™ roadmap, as this diverts energy from core development. Some major suggestions might become available in the long-term or might never eventuate, such as the availability of a Live Whonix ™ CD/DVD.

This is essentially also a debate on priorities which is mostly pointless to discuss due to skill limitations and limitations of users to imagine the difficulty of implementing things where pure logic doesn’t apply without technical background knowledge.

https://www.qubes-os.org/doc/firewall/ is not a whitelisting mechanism. It’s a firewall gui utility and quite some issues with it:

whonix-firewall doesn’t prevent you from doing port filtering. You can modify the iptables firewall rules as per usual linux command line tools or by editing the firewall script.

Very useful, because…

Either that, and/or coming to mind just now, alternatively Whonix Control Panel (on the host could give an easy choice for most if not all items on the list except forums vs javascript).

If the world depends on me, there’s something wrong with the world, not me.

1 Like

I did give Qubes firewall as an example but I never intended to ask the Whonix equivalent include any GUI.

A dedicated text file, with rules in a clear syntax will do great, and be more manageable / safer for users to mess with (lower impact of mistakes) than editing iptables or firewall scripts. I’m thinking something that only allows users to add more limitations, never to remove or revise the core Whonix rules.

So we essentially “just” need a script that reads such a file, validates syntax (outputs errors accordingly, or just rejects the file), and writes the additional restrictions to iptables.

Similarly, I will be very happy with a simple configuration file.

Another one:

It may be possible to have it disabled by default - something I’ve personally asked about before, but we run into the problem of asking users if they want it enabled and then confusion.

Qubes has secure clipboard. KVM disables it by default. You may want to revise that statement.

Here’s the thing. Even an LCD can be a side-channel leaking its displayed contents to nearby mics due to changes in its coil noise according to what’s displayed. This is a practical attack. Things start going off the deep end once all facts are considered. Surely you can’t recommend users going on without a screen to do their computing. Not even a commandline only machine is safe.

Back to the main point. If I was to disable audio - which we still haven’t decided on until Patrick consults the Qubes people, this still leaves other browsers and VMs on the host exposed. If a security minded user were to add it back they would be running round with an open mic if they hadn’t even through to read about this problem.

Firejail is shipped, we do need volunteers to support users and maintain profiles.

If you are “smart” enough to avoid JS but still need Whonix support, you can se our mailing lists.


Each task requires a different kind of expertise. Nothing currently being done is distracting from what could be done had we had knowledgeable people to do them.


Yet, there’d be a lot less discussion compared the forums. But this inspired an idea…

1 Like

Correct, I was referring mainly to VBox. However your reply just strengthens the validity of my point. Why is it disabled on KVM and already secure on Qubes but being left less secure on VirtualBox? Do virtualbox users require less safety? are they less prone to making mistakes?

If there is a way to mitigate that, let’s take it. If not, at least mitigate threats we can. I would assume controlling speakers allows an adversary a higher quality, accuracy and range of transmission than through the LCD coil noise. Besides, with speakers I can think of attacks not even requiring an infected device nearby. For example: an adversary has a good reason to believe you use a public wifi at a certain airport, large cafe, library. He gets there, and make the speakers play a loud alarm sound, or maybe Beethoven. Busted. Other attacks - play a sound provoking the user to take some action. For example, mail arriving, or a false error sound. Perhaps encourage rebooting the system (then reconnect to another AP). I think the possibilities with speakers control are quite larger.

Not sure I understood what you mean here.

I will read more about it.

I am not convinced giving the whole world (anyone can join) my email address, or even just to a place on whonix server, is much better.

Let’s take a closer look at clipboard sharing.
My argument is it’s used either by advanced users, or in the wrong way, or correctly but in rare cases.

When should Gateway clipboard be used externally?

  • Copy information from Gateway to Workstation: perhaps when user encounters a problem and wants to copy and paste output to the forum? in this case he already engages with support here. He is a problem solver. Any confusion regarding the clipboard will be easily resolved.
  • From workstation to gateway, when changing settings, for example Tor bridges, or maybe adding onion grater profiles, and it’s tricky to copy the text char by char? This isn’t an out-of-the-box usage but a higher level. If user gets to do that we can assume he is capable of handling VirtualBox settings as well, or again, capable to engage with support.

When is Workstation clipboard used externally?

  • When copying information to the gateway, covered above.
  • When copying information from one workstation to another. Using multiple VMs in parallel is an relatively advanced activity and we can assume such users are again able to handle clipboard settings.
  • When copying information from workstation to host. I don’t see how this is generally a good practice, and if anyone needs to do that it is fair to require some (very minimal, really) researching being done.
  • When copying information from host to workstation. I don’t recall ever doing that. Similarly, rare or wrong.

It was disabled once in VirtualBox and then re-enabled.


Why is it disabled on KVM and already

already: “It’s not”. “It’s still.”

KVM “lags behind”. When https://phabricator.whonix.org/T718 was
implemented for VirtualBox, changing KVM was forgotten.

secure on Qubes but

Because Qubes developed a virtualizer graphical user interface from
scratch and innovated a secure copy key sequence. Qubes comes with this
configuration by default for all VMs. Qubes effectively discourages use
of Qubes host for anything except using VMs. It’s not a setting up to


being left less secure on VirtualBox? Do virtualbox users require less safety? are they less prone to making mistakes?

It can be refereed to analogy mentioned in my original post.

As an analogy, is it useful to have a super secure window while at the
same time it’s infeasible to secure the front door.

And more from my original post.

With Whonix the goal is the right balance.


VirtualBox has it’s problems. (
https://www.whonix.org/wiki/KVM#Why_Use_KVM_Over_VirtualBox.3F )

For best security, use Qubes-Whonix:

If there is a way to mitigate that, let’s take it. If not, at least mitigate threats we can.

Same as above. Already mentioned in original post in this thread.

The operation was a success, but the patient died. This style of
development was never applied in the history of Whonix and it won’t be
until Whonix or I got obsoleted.

Besides, with speakers I can think of attacks not even requiring an infected device nearby. For example: an adversary has a good reason to believe you use a public wifi at a certain airport, large cafe, library. He gets there, and make the speakers play a loud alarm sound. Busted. Other attacks - play a sound provoking the user to take some action. For example, mail arriving. I think the possibilities with speakers control are quite larger.

  • Once under observation by whoever, software can do very little.
  • A lot of these apply to the host operating system too.

Not sure I understood what you mean here.

Users of Non-Qubes-Whonix are very likely to use browsers or other VMs
on their host operating system. I.e. they are likely to run Firefox,
other browsers and other applications outside of the virtualizer.

Better options:

https://www.whonix.org/wiki/Hardware_Threat_Minimization#Speaker (just
now added)

I am not convinced giving the whole world (anyone can join) my email address is much better.

Use a separate e-mail address?

(anyone can join)

This means you’d prefer a user to staff private communications only?

xariv via Whonix Forum:

in this case he already engages with support here. He is a problem solver. Any confusion regarding the clipboard will be easily resolved.

  • From workstation to gateway, when changing settings, for example Tor
    bridges, or maybe adding onion grater profiles, and it’s tricky to copy
    the text char by char? This isn’t an out-of-the-box usage but a higher
    level. If user gets to do that we can assume he is capable of handling
    VirtualBox settings as well, or again, capable to engage with support.

These are assumptions I would have made too during times I only engaging
in online discussions, without having learned about usability research,
and without having talked to arbitrary users in real life outside of my
social bubble.

Not the case. Being a problem solver isn’t absolute. It’s on a spectrum
too. If there are too many obstacles in a too short time, even a lot
problem solver type persons give up. Even I, when i search for whatever
software (source code, applications for myself, applications for
Whonix), when I am too much put off by various factors, I won’t even
pursue getting in contact.

Done due to many, real, out of social sphere users complaining? any references?

This claim is quite amazing for me. Based on? All new users need clipboard sharing in gateway? I find it very very hard to justify. What for?

Based on HulaHoop’s reply above, and at another post (he “almost got his fingers burnt too many times”, I am sure I read it quite recently) rather conveniently left as it is, than forgotten. And rightly so!

We can make all kinds of arguments, but let’s not rewrite history.

And how did Qubes’ users learn of this unique and innovative feature? did they flood the mailinglist with angry questions or just abandon Qubes because of this usability hurdle?

As we all know, hardware restrictions apply.

this was an example I thought of in 2 seconds, you can be sure than determined and well funded adversaries will come up with more.

I am sure this is not new to anyone here: a core advantage of Whonix’s architecture is the harder job required from malware to escape from the VM through hypervisor to host.

Of course, but as long as it’s regularly monitored by me it’s still an additional attack vector and potential deanonymization threat vs not using any. Today those forums allow registration with an email address and never checking it again, removing this attack vector. That’s actually a positive.

No, because I don’t think that’s realistic, and I see a value in a community of users.

I am regularly using at least 3 other forums that don’t require javascript or low TBB security levels and users are very happy with more basic features because they value their security and anonymity.

Reading here can be done without JS. I think you should consider why users post here. It’s normally because they have an issue. This isn’t a place to pass the time (and some of the issues they have is “why JS is required here”).

I guess I will get the same reply of “you are an advanced user and try to restrict others’ usability”. So how about a poll?

Do you prefer:

  1. More basic features, with higher security (no javascript required, highest Tor security level possible),
  2. Advanced features, with the risk of fingerprinting and susceptibility to JS and other low-security browser related attacks.
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]