Didn’t realize there was real discussion happening in this thread…
I’ve played with autostart a lot in Qubes 3.2.
My gateways have never been named sys-whonix.
I have multiple gateways configured but only one autostarts.
IIRC any VM that is set as a default in Qubes Global Settings will autostart as well as any VM that is dependency of another autostart VM.
To prevent sys-whonix from autostarting it must be disabled as a defaultVM in Qubes Global Settings (including updateVM, netVM, clockVM, etc). It must also be set to not autostart in VM Settings and no other autostart VMs can depend on sys-whonix in their netVM chain.
Related: One recommendation that should be made with respect to templates: If space allows, never use default downloaded template. This is especially true for whonix-gw & whonix-ws. They should always be cloned first. This ensures that you have a clean template to fall back on. Also, when Whonix-14 comes out, you can upgrade the downloaded template without affecting any existing Whonix-13 templates (ie you can have them side-by-side to ease migration). (Shouldn’t Whonix templates be named as whonix-13-gw, whonix-14-gw, similar to fedora-25, fedora-26, etc?)
I’m not convinced of the necessity of having a disposable sys-whonix / sys-whonix rotation. I think sys-whonix is an order of magnitude safer than say anon-whonix or sys-net. If sys-whonix rotation is going to be recommended then I think it’s important to safely / easily migrate persistent Tor state.
Most of the info regarding entry guard selection is outdated. Here are the proposals implemented in:
0.2.9: The Tor Project / Organization · GitLab
0.3+: The Tor Project / Organization · GitLab
Haven’t had time to study them but clearly a lot of thought has gone into the process - which we would be throwing out by discarding state.
This is a massive edit. I’ll try and get around to it when I have time, if anyone wants to jump in please feel free.
A general impression I have is that its too much info overload, It overwhelms users without much benefit. The average joe doesn;t need to know the life story of cookies, when they were born or who created them. Referencing parent articles and papers would have been enough.
This is a massive edit. I’ll try and get around to it when I have time, if anyone wants to jump in please feel free.
A general impression I have is that its too much info overload, It overwhelms users without much benefit. The average joe doesn;t need to know the life story of cookies, when they were born or who created them. Referencing parent articles and papers would have been enough.
It’s true. I don’t know what I thought when I originally imported that
documentation page from JonDoNym in 2013. It was along the lines
“complete Whonix documentation”, “do at minimum what other projects do
and go beyond that”. It’s a good question, what is within the scope of
the Whonix project and what’s out of scope. We don’t want to bind too
much scarce team time for review/maintenance of auxiliary subjects.
Whonix already scaled beyond what I can reasonable keep up with.
Like the article Nymservers is only maintained by @HulaHoop.
I refuse to fully understand and answer support inquiries about it. Or
to review significant changes. Only the maintainer @HulaHoop will do. I
see it as a piece (of non-controversial) free speech by @HulaHoop. Yet,
it doesn’t harm having it hosted on whonix.org. It’s even cool since
it’s Libre Software, contributing to Whonix generally, and useful to
others. And it doesn’t put any pressure on me.
So perhaps give Data Collection Techniques
only a cursory review not going into every detail? And then we use Template:Maintainer to add @torjunkie as maintainer of it?
Yes. Any topic that isn’t integral to Whonix, or that Whonix doesn’t have unique expertise in, will eventually become unmaintained. The more the text, the greater the burden.
Essential topics should have:
actionable user advice
brief justification
references to support
Also, yes. There can be real value in researching topics thoroughly and compiling information gained from various expert sources into a cohesive, ledgible wiki entry.
How to accomodate both? This is a good opportunity for me to resume my whining from last year. I love the content in the wiki. The presentation and organization, not so much.
Information overload can be helped by segregating non-essential, bonus topics to “advanced, further reading” sections.
Lack of maintenance can be resolved by clearly identifying obsolete entries. Easiest (no intervention) way of doing this is by dating entries like blog posts. Authorship can be assigned as well. (Perhaps, new “Community Research” section.) If entries get audited / updated, then a new date + (co)author can be assigned.
For #1, I have no idea how to accomplish. It would involve moving large sections of pages to other pages, creating new pages, deleting lots of pages, creating / deleting sections, moving pages between sections. It would be relatively easy if I could fork the whole thing and present a unified pull. I don’t see how it’s possible without creating a huge mess in current situation.
I can’t be bothered with all the sys-whonix stuff. Too much effort for marginal use case. So I’m gonna leave all that and just slot in somewhere entr0py’s idea of cloning Whonix templates first etc. as a fallback & noting all the default Qubes Global Settings etc as per the post further above for use of alternative gateways.
(Ironically the system seemed to self-rectify itself after all that, except sys-whonix only auto starts some of the time. Good enough).
Aside: re: Qubes R4 - I’ll be waiting for a bit. Tons of bugs outstanding, no Qubes VM Manager etc is a big downside. Maybe 6 months later after release, when it is actually stable.
Re: Tor info outdated. Noted. Will fix up that relevant Tor section in wiki.
Re: edits you don’t like. Yeh - can probably be trimmed down a bit for cookies, but I do like my other edits to other sections…
Re: Anon-connection-wizard needs 0.3.1 Tor - noted. Needs a line in that section to update to latest Tor versions.
Re: benefits of using later Tor versions (security etc, with some minor risk of breakage), should be noted somewhere (from other thread).
This is how /etc/qubes-rpc/policy/qubes.UpdatesProxy
should look in Qubes R4 with Qubes-Whonix installed.
whonix-ws $default allow,target=sys-whonix
whonix-ws $anyvm deny
whonix-gw $default allow,target=sys-whonix
whonix-gw $anyvm deny
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net
$anyvm $anyvm deny
If you were to clone whonix-gw to whonix-gw-14, and if you were to clone whonix-ws to whonix-ws-14, and if you created sys-whonix-14 and you wanted these TemplateVMs to use that as its ProxyVM, then /etc/qubes-rpc/policy/qubes.UpdatesProxy
should look like this.
whonix-ws $default allow,target=sys-whonix
whonix-ws $anyvm deny
whonix-gw $default allow,target=sys-whonix
whonix-gw $anyvm deny
whonix-ws-14 $default allow,target=sys-whonix-14
whonix-ws-14 $anyvm deny
whonix-gw-14 $default allow,target=sys-whonix-14
whonix-gw-14 $anyvm deny
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
# Default rule for all TemplateVMs - direct the connection to sys-net
$type:TemplateVM $default allow,target=sys-net
$anyvm $anyvm deny
In any case, after upgrading to Qubes R4 and Qubes-Whonix 14, the network setting for any Whonix TemplateVM should be set to none. This is because Qubes R4 uses qrexec based updates proxy. Qubes-Whonix 13 supports that as well after a usual apt-get dist-upgrade.
If you would like to document this, you’re most welcome to!
I think how to use multiple Whonix templates and multiple separate clones of sys-whonix / anon-whonix should also be implemented elsewhere than on the upgrade to Whonix 14 page. Imagine a user who starts with Whonix 14. We shouldn’t redirect to the Whonix 13 → Whonix 14 upgrade page. But this can surely wait until Whonix 14 gets released.
This paper written in 2012 claims that both public and private bridges are trivial to enumerate and block by sophisticated censors, like the Chinese. Anecdotally, we’ve had users here claim that it’s a widely known fact in China that Tor bridges do not work.
Glad to see that Lantern page. Too bad they moved to a pay model. Definitely need to document some alternatives that are free or accept more anonymous payment types. Perhaps, Bitmask VPNs could circumvent extensive censorship.
Btw don’t bother updating Copyright (C) 2012 - 2014 (etc.). No need. If you think I should higher priority to update it, I could do an easy mass search and replace so little manual labor would be used for this.
Btw please don’t edit the upper part of github readmes. To change that content, that goes to debian/control such as for example sdwdate-gui/debian/control at master · Kicksecure/sdwdate-gui · GitHub. From there, README.md is sometimes auto generated. 80 characters per line maximum. I am not sure how many people read package descriptions besides reviewers. Would be more important if any Whonix packages made it into packages.debian.org.
Very good new boxes for circumvention rather than tunnels!
I’ve been told, users don’t know which part of their connection gets censored. If they cannot access a website over clearnet, they don’t know that it is probably their network censoring the website and that circumvention tools would help. Many users don’t even know they are behind censorship. Even when they are using Tor for circumvention and cannot reach singular website, they might still think it is somehow their censor that is preventing that connection.
User → Tor → proxy/VPN/SSH → Internet
User → proxy/VPN/SSH → Tor → Internet
Makes a lot sense in our bubble, but I would appreciate if you could please kindly check if we explain this well when we try to take their perspective since you’ve been doing a good job pointing such bubbling issues out. Like when someone using Tor to circumvent, and a website is not reachable over Tor, using bridges would - for us - maybe not user - obviously - not help to fix the issue. Maybe the bridges page should have an overview “good for”, “not good for” or something? Even the page name “bridges” is not thinking from the perspective “what is the user trying to solve”?
I’ll try and edit these via Github. I’ve signed up, but they flagged the account because of Tor sign-up I think. So, I’ve asked them to unflag it - probably will take a while over X-Mas.
No problem, will look at this other stuff too and might do a mass find & replace for “Icedove” and change it to “Thunderbird” in the mean time and a few other low priority things.
PS Merry X-Mas and a happy New Year to the Whonix crew!
All the main contributors seem to be back now, Whonix 14 is close, and you’ve got some $ to employ new people - that’s great. Please share some info about the Linux developer stuff when you have a chance.
Presumably the new blood will focus on bugs, code clean up, and long-awaited minor changes to Whonix from the phabricator list, as opposed to new features.
There are lots of little things in the backlog that the current small Whonix team never have time to get to. Hopefully new programmers should be able to resolve a large number fairly easily and give the community the biggest bang for the buck.
The community is getting noticeably larger, but Whonix still seems to lack the vibrancy for community-based commits (code or documentation) compared to Qubes, and the mothership (Tor). Not sure why that is, but hopefully the positive trajectory continues.
Has the apparmor profile for Thunderbird in Whonix 14 been changed to apparmor-profile-thunderbird ?
Right now the instructions still reference:
sudo apt-get install apparmor-profile-icedove
Which I changed in edits to:
sudo apt-get install apparmor-profile-thunderbird
Not sure if that is actually correct. If not, that profile/package should be renamed in Whonix 14 (?)
I changed all “Icedove” references to “Thunderbird” in the wiki, where appropriate.
Also, I changed all “Iceweasel” references to “Firefox ESR” where appropriate, since that branding issue was rectified in mid-2016 (see the Debian note about it).
It was along the lines
