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,