diff --git a/content/posts/qubes/index.md b/content/posts/qubes/index.md index c91818d..dae0d8d 100644 --- a/content/posts/qubes/index.md +++ b/content/posts/qubes/index.md @@ -65,7 +65,7 @@ Another security feature of the Qubes OS structure is that the App qubes don't h # When to Use Tails vs. Qubes OS -Put simply, Tails is anti-forensic, and Qubes-Whonix is more secure. +Put simply, Tails is easier to use and better protects against *forensics*, while Qubes-Whonix better protects against malware. Qubes OS includes Whonix by default (Qubes-Whonix) for when you want to force all connections through Tor. As compared by [Privacy Guides](https://www.privacyguides.org/desktop/#anonymity-focused-distributions) (emphasis added): @@ -90,7 +90,7 @@ And to use Qubes OS: * As an everyday computer * For sanitizing untrusted files * For tasks or workflows where Tails is too restrictive -* For increased security in a project, *if* you will be storing sensitive project data long-term on an encrypted volume anyways, because this long-term storage negates the anti-forensic property of Tails. For example, a project's private PGP key needs to be stored long-term, so the benefit of using Tails is negated but the benefit of using Qubes-Whonix remains (increased security). +* For increased security against malware in a project, *if* you will be storing sensitive project data long-term on an encrypted volume anyways, because this long-term storage negates the anti-forensic property of Tails. For example, a project's private PGP key needs to be stored long-term, so the benefit of using Tails is negated but the benefit of using Qubes-Whonix remains (increased security against malware). Keep in mind that with Tails it is easy to destroy an encrypted USB you no longer need in order to revert to a blank slate of "no trace", but the equivalent with Qubes OS requires destroying the hard drive. @@ -412,7 +412,7 @@ To address "future not-yet-identified vulnerabilities of this kind" on older har * sys-net: Disposable. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before activities that require sys-net (i.e. email, ssh sessions, etc.). * [vault qube](#how-to-organize-your-qubes): * Instead of having only one vault qube that stores all files (as described above), you can compartmentalize by having different vault qubes dedicated to specific activities (i.e. `vault-personal`, `vault-project1`, etc.). This means that if a networked qube is compromised while working on project1, [intentional sniffing](https://www.qubes-os.org/doc/data-leaks/) will not have potential access to all files, but only to those files that are compartmentalized for project1. - * Configure KeePassXC to lock when it is unused: **Application Settings → Security → Timeouts**, enable **Lock databases after inactivity**. If you need a password when using an untrusted qube: + * Configure KeePassXC to lock when it is unused: **Application Settings → Security → Timeouts**, enable **Lock databases after inactivity**. Configure [automatic clipboard wiping](https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#automatic-clipboard-wiping), which is disabled by default. If you need a password when using an untrusted qube: * "Emergency pause" the untrusted qube(s), * start the necessary vault qube and open the KeePassXC database, * copy the credential to the global clipboard,