I’m not sure what that is. I do prefer more whitespace to less. For example, Tor Browser Essentials has gotten difficult to read. Part of the reason also is because = Heading = is too big relative to body text and should only be used sparingly for main chapters. I prefer ==== Heading ==== to divide subchapters.
I understand why this warning is necessary - namely, there is no way to enforce the behavior that we want.
On the other hand, users shouldn’t be scared into thinking that the process is somehow unpredictable or inherently risky. If directions are followed, there is virtually no chance of using an out-of-date or wrong Tor Browser version. I started using Whonix DispVMs when I wrote my first post in the other thread nearly 7 months ago. Since then (as far as I can remember), I’ve only updated my Tor Browser using the Internal Updater, which pops up within a few seconds of launching Tor Browser in any DispVM. In fact, the annoyance of the pop-up leads one to update the DisposableVM-Template as soon as possible.
Related note: The default update setting in TB preferences is to update automatically. I set mine to notify-only since having every DispVM update automatically is annoying x2.
Added instructions for TBB-alpha. Alpha users are grown-ups so they only get cli. Used the expand button with a separator at the bottom - would be nice to be able to put the whole expand section in a box.
Added some nitpicks back at ya. It’s ready to go I think. I wonder if stylometry algorithms can pick up multiple writers.
Of course, this is not considering the results of Application Customization and Privacy Issues. Hope that doesn’t necessitate a rewrite. 
You’ve done an amazing job on the wiki entry! Well done to both of you.
Tester Report on Wiki Entry Correctness (Qubes 3.2)
From a clean state:
- Creating a fresh Whonix-WS dispVM works;
- Adding the Tor Browser and Konsole entries to the XFCE menu for dispVM works;
- Tor Browser XFCE entry successfully launches within the Whonix-WS dispVM;
- The customized Whonix-WS dispVM remembers Javascript, slider and add-on changes with the touch command for the standard 6.0.7 Tor Browser (well done!);
- cli commands for updating the customized Whonix-WS dispVM to reflect the preference for the 6.5a5-hardened browser works; and
- Re-running the touch commands to customized settings for the hardened Tor Browser also works (even better!).
100% success!
Wiki Small Typo
Change:
If you intent to spawn DisposableVMs from other VMs
→
If you intend to spawn DisposableVMs from other VMs
Suggested Additions
One x additional footnote in the ‘Updating Tor Browser’ section (somewhere):
Prior to installing the Tor Browser in the DisposableVM-Template, check the Tor Project signing keys match those found online at: How can we help? | Tor Project | Support
&
Edit footnote 28 to say:
Advanced users can also select the hardened Tor Browser at this step before recreating the DisposableTemplateVM.
1 Like
entr0py:
I understand why this warning is necessary - namely, there is no way to enforce the behavior that we want.
On the other hand, users shouldn’t be scared into thinking that the process is somehow unpredictable or inherently risky. If directions are followed, there is virtually no chance of using an out-of-date or wrong Tor Browser version. I started using Whonix DispVMs when I wrote my first post in the other thread nearly 7 months ago. Since then (as far as I can remember), I’ve only updated my Tor Browser using the Internal Updater, which pops up within a few seconds of launching Tor Browser in any DispVM. In fact, the annoyance of the pop-up leads one to update the DisposableVM-Template as soon as possible.
Related note: The default update setting in TB preferences is to update automatically. I set mine to notify-only since having every DispVM update automatically is annoying x2.
I guess you are not just referring to the specific “check Tor Browser
warning” but also the general “Advanced users only!” warning at the very
top of that wiki page?
Sure. I am all for describing things as close to The One Truth ™ as
possible. If you see a way to rewrite the warnings so they sound more
accurate, please go for it.
My intention with the general “Advanced users only!” warning is just to
make sure users read these documentation before using DispVMs. Then
DispVMs are great. However, just “qvm-create-default-dvm” and then use
Firefox in the DispVM and expect anonymity is a failure I like to prevent.
entr0py:
[quote=“Patrick, post:14, topic:3232”] I don’t like the two new lines
so much. [/quote]I’m not sure what that is.
It is:
text
other text
What about rather using a dividing line (which also results in enough
white space)?
texttorjunkie:
You’ve done an amazing job on the wiki entry! Well done to both of you.
Thanks! Also of to thank you! 
I’ll try your ‘untested’ entries to check they actually work with Qubes 3.2 eg XFCE menu entries and so on.
That’s great!
No, I was just pointing out that updating TB in a DispVM-Template works reliably. I agree with Advanced User Warning because current state of DispVMs is ambiguous, messy, difficult to understand completely.
My preference right now I think is:
---- ;separator
## Main Chapter ##
#### Sub Chapter ####
##### Main Steps #####
''' Sub Steps ''' ;don't need to be indexed
---- ;separator
also, separators with expand sections, because it’s hard to tell where they end.
1 Like
Sounds good!
todo: needs resolution of tb-updater experimental --alpha, --beta, --rc, --hardened options - #3 by Patrick
I don’t think so. In Whonix 13 it does not matter since tb-updater shows all Tor Browser versions anyhow. It matters for Whonix 14. So in meanwhile this can be removed from DispVM documentation. [And I guess for Whonix 14 it’s best to keep it like in Whonix 13.]
Yes.
For chapter Qubes Disposables I was wondering… To make the separator more visible, what about another
'''headline'''
before the text for non-advanced, regular users starts? Any idea for a headline?
Done. Looks better.
Are you suggesting removing Option #1 entirely? The point of that option is that it should be a simpler method for TBB-alpha users who don’t want a customized DispVM-Template. Also, they’ll probably be making the appropriate changes to whonix-ws anyway so they can have TBB-alpha in their AppVMs. However, I’m not even sure if it works. That was the reason I asked Qubes DispVM technical discussion - #10 by entr0py.
Reasons to get rid of Option #1 even if it works:
- @torjunkie confirmed that Option #2 works. and advanced users would probably want customization enabled so they can keep changes for testing.
- (IIUC) Option #1 would require recopying TBB from /var/cache every time a change is made to whonix-ws; for example, due to daily update maintenance. Probably not a big deal.
No. Just the sentence todo: needs resolution of https://forums.whonix.org/t/tb-updater-experimental-alpha-beta-rc-hardened-options/781/3 gotta be replaced with real content.
entr0py:
The point of that
option is that it should be a simpler method for TBB-alpha users who
don’t want a customized DispVM-Template.
Sounds reasonable.
Reasons to get rid of Option #1 even if it works:
- @torjunkie confirmed that Option #2 works. and advanced users
would probably want customization enabled so they can keep changes
for testing.
I don’t think all advanced users want DispVM customization. I add myself
to that group.
Ok, I just remembered why Option #1 is hard: Using Whonix-Workstation as a DisposableVM (DispVM) - #20 by Patrick
IIUC, there is no way to set tb-updater to permanently get the latest version of a specific type of TBB (alpha, hardened). Without this feature, user must manually update TBB via update-torbrowser every time a new TBB is released. This is the issue I wanted resolved before documenting Option #1. In the present state, Option #1 would look something like this:
- run update-torbrowser in whonix-ws
- qvm-create-default-dvm whonix-ws
- every time you change whonix-ws, tbb will be recopied but that’s ok because the version you wanted will still be present in /var/cache
- when new tbb is released, pay attention and run update-torbrowser again in whonix-ws. if you forget, then stable tbb will be copied to your dispVM-templates. Better idea is to set tb_install_follow=false. Then run update-torbrowser in whonix-ws when TBB internal updater prompts for upgrade.
I guess that’s not so bad. With auto tb-updater though would be simpler:
- set preferred tbb type in whonix-ws
- qvm-create-default-dvm whonix-ws
No further maintenance required. DispVM-Template TBB will always be what you wanted.
Should I document current Option #1, wait for change to tb-updater, or omit entirely?
You just have to be different… 
Ah, great, thanks for summarzing it!
Right.
(I am keeping releasing tb-updater package upgrades with bumped (stable) hardcoded version numbers (tbb_hardcoded_version), because I am not trusting the auto detection is going to work forever. When RecommendedTBBVersions format changes as it did a few times in past, the version auto detection breaks. [tbb_hardcoded_version is set to the stable, since That is the recommended version by Torproject, most stable, least maintenance overhead.])
Another future feature could be to ship two versions of tbb_hardcoded_version. One for default, for most, for stable users and another one with the most reasonable alpha (would be now: hardened). I didn’t go for this, because it would increase maintenance overhead. (More tb-upgrader stable upgrades, not only for new stable Tor Browser releases, but also for each new alpha.)
An alternative additional(!) future feature [disabled by default] could be to auto detect the highest available version number of a configurable release channel (terminology used by Tor Browser about menu) (for example: stable or hardened). tb-updater would also need a feature to auto run. But when, and how(!) would in Qubes TempalteVMs be a good time to auto run? The how is a big question mark. There are no hooks into apt-get update or apt-get dist-upgrade. Only dpkg hooks. And running tb-updater every time dpkg runs seems wrong.
Right. I don’t see any way around that as of Whonix 13. And for Whonix 14, we’d still need to draft a feature (as per above).
As of Whonix 13 without any of the features described above, I think tb_install_follow=false should be mandatory for anyone wanting to use hardened. (With a reminder to recheck for Whonix 14. Maybe we’ll think of something.)
Please add.
1 Like
Sure?
sudo dnf install xfdesktop
Why not qubes-dom0-update?
Quote marmarek:
In principle it will be possible to start an AppVM in “disposable”
mode - which means changes to its private image (in addition to root
image as in normal AppVM) will be discarded after VM shutdown.
Technically any AppVM can be used for that, but practically it makes
sense to have dedicated “DispVM template” AppVMs (as currently
fedora-xx-dvm).
This will be so awesome! Fix most of the complications we are facing.
No, that’s not right. Result of not being able to test my own instructions. Plus, that step can be omitted completely if xfdesktop is installed automatically by Qubes dom0, which most likely it is - but I can’t check.
Please see if xfdesktop is already installed on your 3.2 system, then we can remove that step.
Also, if you are willing, there will be a new set of untested instructions in the ‘Expand’ section of Qubes Disposables under Option #1.
Thanks!
1 Like
I can confirm xfdesktop was installed for me already.
Yes. Please do. Going easy on regular users and going hard on advanced users and testers. The Only Way ™ forward.
Qubes-Whonix DisposableVM documentation created blog post public preview:
Any feedback?
Please sign up for the wiki (and tell me your account name so I can upgrade it) if you like to edit that blog post or post other stuff.
1 Like
Perhaps paraphrase relevant content from the wiki, Qubes docs and Joanna, so that normal users understand the point of using a Whonix-WS DispVM.
Recommended blog change:
Before we had just a stub. Now, Qubes-Whonix DisposableVMs are fully documented thanks to contributions by the community.
What are DisposableVMs?
Under the Qubes TemplateVM model, any changes made to a TemplateBasedVM’s root filesystem are lost upon reboot. This is advantageous for several reasons: it allows centralized (and therefore faster) updates for all applications (most) inside the root filesystem, saves time and disk space.
However, certain directories are designed to persist between reboots in order to store files and settings. These directories are stored in /rw/ and include /home/user as well as additional directories defined by “bind directory” settings.
To ensure that all changes to the filesystem are discarded after a session, Qubes offers DisposableVMs. When a DisposableVM is shutdown, the VM is removed from Qubes and all related VM images are deleted from the host filesystem.
What is a Whonix-Workstation DisposableVM?
As the name suggests, this is a Qubes DisposableVM template based on the Whonix-Workstation. This allows Qubes-Whonix users to create throw-away instances of their Whonix-Workstation.
Importantly, the Whonix-Workstation DisposableVM will inherit the netVM and firewall settings of the ancestor VM by default, meaning the Whonix-Gateway will be safely used.
Why Should I Consider Using a Whonix-Workstation DisposableVM?
Whonix-Workstation DisposableVMs:
- Are quickly generated;
- Are disposed of (deleted) when the user has finished browsing and other activities in a single session; and
- Will not remember any of the user’s activities across DisposableVM sessions, unless customized.
The major benefit of this approach is that the Whonix-Workstation DisposableVM can be created in order to host a single application - usually the Tor Browser - without any risk that a compromise of the browser will effect any of your other VMs.
Critically, a Tor Browser exploit will not effect (poison) later instances of the Tor Browser running in a subsequent DisposableVM session, because the DisposableVM is always started in a clean state.
Can I Customize Whonix-Workstation DisposableVMs?
Yes. For advanced users, the instructions include steps to create a customized savefile that will remember specific changes, such as personalized Tor Browser settings. Due to concerns over possible fingerprinting issues, users should carefully read the wiki warnings before proceeding on this course of action.
Can I Easily Add DisposableVM Entries to the Qubes Menu?
Yes. Steps have been included which successfully create entries to the XFCE4 menu in Qubes 3.2.
What Else Should I Know?
Due to a few usability issues affecting anonymity, do not use Whonix-Workstation DisposableVMs until:
- You understand Whonix-WS DispoableVMs are NOT yet amnesic; and
- Have carefully read and understood the available Qubes-Whonix DisposableVM documentation.
Alternatively, you may wish to wait for Qubes 4.0 [1] before you start using Qubes DisposableVMs, due to significant enhancements planned for the later release.
2 Likes
Amazing work!
Do you mean chapter Qubes 3.2 / XFCE4 - menulibre (untested) by that? If so, the (untested) should e removed from the wiki.
Since chapter Qubes 3.2 / XFCE4 - menulibre (untested) modified whonix-ws-dvm /home/user, doesn’t it require using a customized DispVM, i.e. /home/user/.qubes-dispvm-customized?