A look at https://www.torproject.org/projects/projects reveals that while Tails is considered part of the Tor project family Whonix is somehow not. Why does the Tor project not endorse Whonix openly and fully? Are there security reservations? It would seem that using Tor Browser in Whonix is at the very least as secure as using Tor Browser directly on the host system. I mention Tor Browser because it’s their flagship product, and Whonix torifies everything else anyway.
I’ve always thought it was a big failing of the Tor Project to not endorse Whonix, since it’s safer, and has persistent guards unlike Tails, which means tracking of Tails users is far easier for global adversaries.
I don’t think its a deliberate decision to not endorse us. We haven’t really pushed for it. They are very busy and may not have given it much thought but I know many TPO devs do like our distro and use it. They also been helpful in discussing dev topics and even accommodating out our split design with some features.
For users without an overview or familiarity with either project, it would be greatly reassuring to know the Tor project recognizes Whonix and encourages Tor to be used with it. It is after all the ultimate authority on all things Tor. Such a stance would encourage more people to use Whonix. There are lots of warnings about how Whonix is experimental software. In absence of any kind of opinion from the Tor project it could look to someone like it might just be better to stick to a more well known and proven option and simply use Tor browser. If an endorsement or supportive opinion is justified I don’t see how it could hurt.
Given the loss of a webmaster, limited funding, and a very lean team at the moment, I’m more interested in Whonix community support of Whonix.
People only need look at commits to see there are only a handful who consistently contribute right now to code. A few only contribute to the wiki etc.
I’m not sure why the Whonix community is not standing up and supporting the platform they love and use daily. Particularly when the main contributors busted their balls in recent times, running the project on the smell of an oily rag and tons of free effort.
It’s a big disappointment when you look by comparison at how vibrant the contributions are over at Qubes or the Tor Project.
It really poses some interesting questions:
Why aren’t coders interested in digging into Whonix stuff?
Wiki edits and contributions are relatively simple. What stops people tapping on their keyboards?
There is definitely significant expertise in the community, but the efforts seem fragmented in side projects or separate privacy guides etc, instead of doing it within the Whonix project. Why aren’t these guides/coding efforts contributed directly into the wiki, Whonix commits etc. instead?
If Whonix had the manpower to plough through issues/bugs at the rate you see on Qubes github or Tor trac - fully supported by the community - it would have already been fully-featured with all the bells and whistles that people keep querying in the forums here and there over the years, instead of lots of manual fiddling that is required.
It is not an ideal model in the long-term, and the community needs to man up, or stop whinging when their latest anonymity network or protocol doesn’t play nicely with Whonix, without a lot of configuration.
i’ve been thinking about that a lot more over the past year in regards to the guide i work on. here’s my only concern about it. the guide i work on is aimed at a relatively niche use case (new users to debian and whonix). it is specific involving the steps to take and the tools that are used, rather than general. and when it fails, it fails miserably, largely due to services no longer being available.
my concern with incorporating much of what i do with the guide into the whonix wiki is that it may come off as endorsements of specific services or software via whonix. Additionally, when such services or software cease to exist or function, it would reflect on the whonix project if unresolved if incorporated into the wiki, rather than my own personal efforts which, due to the “new user” focus, can become more problematic. i am comfortable with complaints coming my way in that regard rather than towards the whonix project.
at the moment, for the number of issues that have come up all at once with the beta version of the new guide i’m working on (discontinued software coupled with service access issues via tor), i’m reminded of the same issues that came up with a new version of the guide immediately post-snowden leaks in mid-2013 with software and services going down for various reasons. it resulted in a delay of the release of the new version to the tune of months.
that being said, if there are any areas where the wiki needs some support where i can contribute, i am willing. you have mentioned before about cherry picking from the guide i work on to add to sections of the wiki. i will most likely continue to publish my guide. but for the sections of the guide that can be incorporated into the wiki, i am certainly willing to do that without requiring others to cherry pick with each new release.
i used to offer the guide i work on in wiki format. so, i could certainly explore adding sections of it to the whonix wiki. were there specific areas of it you found useful for general whonix purposes? i am not finding an immediately accessible “private message” function in the forum. if you want to discuss outside of this topic, my twitter and gpg for email is available in my profile.
I definitely had your guide in mind (at least some sections). I’ve never gotten around to cherry picking it as we discussed some time ago.
What I think is excellent and would definitely benefit the Whonix wiki is the full blown section you have on setting up encrypted email i.e. steps 1 - 100 or thereabouts, plus the pics you had in there.
Our wiki at the moment is very much advocating PGP key use and finding a reasonable provider, but doesn’t provide clear steps as per your guide. This means in reality that most users won’t ever achieve this, as it is complex and challenging task, even for seasoned users.
Basically, if you like, I can create a page for “Generating PGP Keys and Encrypted Email Setup” or similar, and I think we could use your steps exactly as they are already to populate it. We/you could snapshot all the relevant pics and upload it to the Whonix server also.
The page would clearly identify that the material is borrowed holus bolus from your guide in the attribution section, with a note somewhere similar to “Gratitude is expressed to tempest for permission to use this material for the Whonix wiki. The original source material can be found at: [insert address].” The reference would also point to your permission in this forum.
How does that sound? Do you mind pointing to your latest version of the guide in this forum please (haven’t seen it for a few months)?
There was other good stuff in there too from memory which is suitable for the wiki, but I don’t recall specifically what that was.
@torjunkie i have a beta release that was near ready for final publication over the last month. then, a few issues came up.
vfemail.net has changed their registration process to make it near impossible to register for an account over tor. recaptcha v2 is used in the registration process. on vfemail’s onion, the recaptcha will not appear, thus making registration impossible there. on the clear net, the initial click on the recaptcha box opens a new tab to an ad site. when clicking on it again, it now claims that “too many connections bl blah blah” more often than not and won’t allow registration. i have contacted the admin a number of times over the past month on this but have yet to receive a response. they are usually very good about responding, so i do not know what is happening here.
thus, i am in the process of searching for a new free email service with an onion that does not require any additional shenanigans for registration and has a competent enough admin to keep the domain out of spam blacklists. so far, this has been exceedingly dificult due to various other providers requiring an additional email address for verification. the other issue is that, for the small handful i have found that do not require email address, phone numbers, etc., they are relatively new with entirely unknown admins, which is problematic from a “trust” scenario. (yes, i know. trusting email providers is wrong. “use gpg.” however, some services require an email address for verification and do not implement gpg in that process, which makes them easy to exploit by malicious email admins if their users use the email for services like twitter).
tor messenger developer, rather abruptly, announced the end of the project 3 days ago. the beta version of the guide has a completely rewritten chapter on instant messaging using tor messenger. so that has to be redone from scratch. now torn between gajim (for the omemo support) or coyim.
virtualbox in debian stretch is in backports repo. after publication of multiple vulnerabilities a couple months ago, the version in stretch-backports is still vulnerable. so, need to redo the guide to use oracle’s debian repo. however, that destroys process of having all operating system updates done via onion servers. i would prefer to use kvm for the guide. however, i have not discovered a simple means to have an immutible core system with kvm that is similar to what the guide implements with virtualbox. if an additional virtual hard drive is added to the whonix vm for storage purposes, and it is excluded from a snapshot, virsh throws an error.
thanks, @hulahoop. i have considered that and got it working fine that way. only concern is exposing the host drive to the vm. thus, was trying to find a means to have it all contained to virtual drives instead if possible.
@Algernon i have considered it. but, at that point, i basically end up with a custom distro i would have to support. since one point of the guide is to get people a little more comfortable with the various ways of interacting with linux, i have opted not to do a custom iso for distribution at this point.
@torjunkie i have tried cicada mail in the past and, for set up, it worked fine. while this may sound odd given the context of the guide, my main concern about cicada mail is that the admins are not known. for an e-mail provider, a known admin usually is a good indicator that they will take the steps required to not become a banned spam outfit. thank you for the info though. given that registration on vfemail.net has become problematic, cadamail may end up being one of the only remaining viable options.