diff --git a/README.md b/README.md
index b7cda83..1d5d6b9 100644
--- a/README.md
+++ b/README.md
@@ -19,6 +19,9 @@
 - [Browsing](#browsing)
     - [Browser Configuration](#browser-configuration)
     - [Search Engine](#search-engine)
+      - [DuckDuckGo](#duckduckgo)
+      - [SearX](#searx)
+      - [Whoogle](#whoogle)
 - [Live Boot](#live-boot)
 - [Physical Destruction](#physical-destruction)
 - [Cryptography](#cryptography)
@@ -145,7 +148,7 @@ Researching the right operating system (OS) for your specific operation can be a
 ### Desktop
 For desktop, this process eliminates Windows, Macintosh, and ChromiumOS/CloudReady from the race. While there are significant attempts at undermining telemetry on these distributions, this requires a substantial amount of effort that is bound to corrupt processes and retain the bloat from disabled software.
 
->Note: Solutions with Windows variants aren't necessarily the anti-thesis to anti-forensics. These systems have excessive bloat, however they can pursue the same aims. Windows provides many areas to hide files amongst the system. Windows systems can also be an overload to inexperienced investigators with the caches, shellbags, shortcut files, monolithic registry hives, and a myriad of ways to set persistence mechanisms. This could force investigators to expend more time in the investigation. The reason it is avoided in this book is due to the proprietary blobs, bloatware, legacy protocols (which will continue to render it vulnerable to exploitation), and excess telemetry. In good faith, one could not claim to provide secure cryptography on a system that was designed for the aims of counterinsurgency.
+> Note: Solutions with Windows variants aren't necessarily the anti-thesis to anti-forensics. These systems have excessive bloat, however they can pursue the same aims. Windows provides many areas to hide files amongst the system. Windows systems can also be an overload to inexperienced investigators with the caches, shellbags, shortcut files, monolithic registry hives, and a myriad of ways to set persistence mechanisms. This could force investigators to expend more time in the investigation. The reason it is avoided in this book is due to the proprietary blobs, bloatware, legacy protocols (which will continue to render it vulnerable to exploitation), and excess telemetry. In good faith, one could not claim to provide secure cryptography on a system that was designed for the aims of counterinsurgency.
 
 For dangerous operations, Linux, BSD, and Xen variants, along with a select number of mobile distributions are the only true solutions. There are hundreds of derivatives to sift through for Linux. Regarding Xen and BSD, one should consider QubesOS or HardenedBSD respectively.
 
@@ -157,7 +160,7 @@ At the time of writing, the only anti-forensic friendly distributions designed t
 
 One more factor to consider for the OS selection is the service manager being used. There are plenty of security enthusiasts who justifiably denounce the use of the SystemD service manager (used to spawn processes like networking, scheduled tasks, logging, etc).[^8] There are a variety of service managers that have less bloat and a more simple codebase - OpenRC, runit, etc. The fact that most of these OSs are open-source results in the problem of funding. A side-project that has peaked a developer's interest often go long durations (if not permanently) without any efforts to maintain/patch. Some recommended OS alternatives without SystemD at the time of writing include Artix (Arch variant)[^9], Void Linux[^10], and Alpine Linux[^11].
 
->Note: Ideally, an operating system running a micro-kernel (minimal core) such as seL4 could be in the running. At the time of writing, these alternatives are still too adolescent to advise with little community support.
+> Note: Ideally, an operating system running a micro-kernel (minimal core) such as seL4 could be in the running. At the time of writing, these alternatives are still too adolescent to advise with little community support.
 
 ### Mobile
 For mobile devices, options are extraordinarily limited. Phones are designed to constantly ping telecommunications infrastructure and receive incoming packets by design. The core purpose is to be reached. Google, Apple, and other players in the telecommunications industry have taken this to an intrusive extent. Android stock phones home an average of 90 times per hour. Apple accounts for at least 18 times per hour.[^12] Both operating systems do not operate in a manner that is conducive to privacy. It seems that the only remaining options are to disable all sync capabilities on iPhone, or flash an open-source operating system to an Android.
@@ -178,7 +181,7 @@ systemctl disable rsyslog.service
 systemctl disable systemd-journald.service
 ```
 
->Note: These commands will not work on systems running lightweight service managers such as OpenRC, runit, or S6, nor is this comprehensive.
+> Note: These commands will not work on systems running lightweight service managers such as OpenRC, runit, or S6, nor is this comprehensive.
 
 While it is wise to reduce your logging footprint locally on your device, full disk encryption (FDE) is a sufficient anti-forensic mitigation for logging. If the attacker obtains access to your device as it is running (either physical or remote via a security compromise), logging is likely the least of your concerns.
 
@@ -188,7 +191,7 @@ Deletion of files in most operating systems today is a loose version of the term
 A simple shred command in a Linux bash shell: `shred -n 32 -z -u <FILE>`
 This command would use GNU coreutils shred function to wipe over the designated file with 32 iterations. The -z adds a final overwrite to hide the shredding process, and the -u unlinks the file completely.
 
->Note: This is an example command; I am not recommending 32 overwrites.
+> Note: This is an example command; I am not recommending 32 overwrites.
 
 The NSA has in the past developed malicious firmware for HDDs that can create secret copies of user-written data. SSDs which make use of wear-leveling cannot have information securely erased by the user.  However, SSDs with wear leveling also pose a significant annoyance, and even create difficulty for, forensic investigators. Such annoyance cannot be considered a security guarantee. In short, wear-leveling, garbage collection, and trim operations are largely outside of the user's control, therefore "secure" deletion should not be assumed to be possible. Regarding SSDs, trim operations should always be enabled as it stands to make files unreadable using "Deterministic Read After Trim" or "Deterministic Zeroes After Trim." Consider trim as an unreliable backup mitigation to FDE.
 
@@ -256,22 +259,28 @@ To further elaborate, whenever Chromium is executed, it can be ran by typing the
 These flags can also be appended directly to the `/usr/bin/Chromium` file so every execution forces the use of the flags. (See browser hardening configurations from Anonymous Planet[^30]).
 
 ### Search Engine Selection
+
 #### DuckDuckGo
-DuckDuckGo (DDG)[^31] has long been used as an alternative to Google. It is worth mentioning that DDG is the TOR Project's default selection. This has granted them significant notoriety and inherent trust. There are some underlying problems with DDG such as being based in the US, and they are not completely open-source. Without having reviewable source code, there is no way of validating their seemingly well-intentioned privacy mission statement. However, source code review becomes a moot point when you consider the fact that you are using their centralized services. Odds are that the providers of the service do not make the entirety of their systems publicly reviewable/auditable. Arbitrary code or excess applications could exist on their servers.
+DuckDuckGo (DDG)[^31] has long been used as an alternative to Google. It is worth mentioning that DDG is the TOR Project's default selection. This has granted them significant notoriety and inherent trust. There are some underlying problems with DDG such as being based in the US, and they are not completely open-source. Without having reviewable source code, there is no way of validating their seemingly well-intentioned privacy mission statement. However, source code review becomes a moot point when you consider the fact that you are using their centralized services. Odds are that the providers of the service do not make the entirety of their systems publicly available for audit. Arbitrary code, dependencies, or excess applications could exist on their servers.
 
-#### Searx
-Searx instances[^32] are decentralized search engines that can be stood up by anyone. Decentralization with Searx doesn't remove the issue of inherent trust that must be placed in the instances, but it ensures that you have control in where you place your trust. This also enables people to stand up their own instances and configure them with better protections. Decentralization is preferred, however some of the instances are likely ran by intelligence agencies.
+#### SearX
+SearX or SearXNG instances[^32] are open-source meta-search engines with the aim of protecting user privacy by removing reliance on centralized search engines, cutting off tracking cookies, and preventing user-profiling-based results modification. These decentralized search engines that can be stood up by anyone. Being able to stand up your own instance can allows users to host with better protections. Instances can also be configured to leverage TOR hidden services.
 
->Note: There are certainly more variants of search engines that I have not covered that are further from the beaten path. The landscape is often changing, and it is advised to practice due diligence when researching alternate search engines. Many of the self-hosted options provide a safer alternative over centralized providers with a monetization model.
+> Note: Decentralization with SearX doesn't remove the issue of inherent trust that must be placed in the instances, but it ensures that you have control in where you place your trust. Decentralization is always preferred to centralization, however there exists a high probability that some of the instances are ran by intelligence agencies.
+
+#### Whoogle
+Whoogle is a search engine designed to specifically pull Google search results with the absence of advertisements, javascript, AMP links, cookies, and IP address tracking. Instances are relatively simple to deploy via  number of ways. If you are a journalist or researcher who does not want results from a single source, you will likely be better off using [SearXNG](#searx).
+
+> Note: There are certainly more variants of search engines that I have not covered that are further from the beaten path. The landscape is often changing, and it is advised to practice due diligence when researching alternate search engines. Many of the self-hosted options provide a safer alternative over centralized providers with a monetization model.
 
 ## Live Boot
 Live media (USB or CD) can be booted from in a process called Live Boot. Data is prevented from being stored on the hard drive of your computer (so long as you do not attempt to decrypt your hard drive that is detected). Nothing lives in permanence from the live boot. This is a useful tool for the privacy conscious as there is little to no cleanup process of your actions. Some operating systems such as The Amnesiac Incognito Live System (TAILS)[^33] are forensic-minded and wipe the data from the device's physical memory once the USB is removed or the system is shutdown. This is not always the case for live media. Be conscious of network activity living on in permanence. This is where the use of strong cryptography can come into play from Virtual Private Network (VPN) configurations to the use of TOR. Live booting reduces the effectiveness of the Cold Boot attacks. Cold boot is heavily reliant upon data that is temporarily stored in Random Access Memory (RAM).
 
->Note: Cold boot attacks require a system to be under attacker control. DDR3 memory modules lose data within 3 seconds of losing power under normal circumstances. DDR4 loses data within 1 second (more like a fraction of a second) after losing power under normal conditions. Sufficient mitigation against cold boot attacks is generally to simply remove memory before control of the system is released. Linux allows this via the "magic" SysRq combo SysRq+o. This is available by default on some OSs, but needs to be enabled manually on others. Parrot enables many SysRq commands by default. Among those allowed by Parrot include SysRq+o (immediate poweroff, with no shutdown cycle).
+> Note: Cold boot attacks require a system to be under attacker control. DDR3 memory modules lose data within 3 seconds of losing power under normal circumstances. DDR4 loses data within 1 second (more like a fraction of a second) after losing power under normal conditions. Sufficient mitigation against cold boot attacks is generally to simply remove memory before control of the system is released. Linux allows this via the "magic" SysRq combo SysRq+o. This is available by default on some OSs, but needs to be enabled manually on others. Parrot enables many SysRq commands by default. Among those allowed by Parrot include SysRq+o (immediate poweroff, with no shutdown cycle).
 
 Systems can be started in non-persistent sessions with the use of `grub-live` and `grub-live-default` packages. `grub-live` boots to persistence by default, while `grub-live-default` starts directly to a non-persistent session.
 
->Note: These packages are primarily available for Debian-based systems
+> Note: These packages are primarily available for Debian-based systems
 
 ## Physical Destruction
 Physical destruction of critical operation data is advised. Institutional authorities such as the National Security Agency (NSA) and Department of Defense (DoD) see no value in the wiping of critical data. If they believe data is at risk or a device under classification is to be removed from a closed area, all media drives must be completely degaussed. The lesson to be learned here is that if authorities do not trust wiping and overwriting methods, be cautious in your operational threat model. If your life depends on the media being sanitized, save yourself the stress and physically destroy it. If your operation would have adverse consequences if you are caught, there is no room for sentiment.
@@ -290,7 +299,7 @@ Destroying SSDs:
 - Burn the remains
 - Separate and scatter the debris[^34]
 
->Note: The Department of Defense (DoD) generally cites a drive wiping policy of 7 passes using random data. Each pass is performed on the entire drive. Other acceptable means of data removal include a single random pass (modern drives make it nearly impossible to recover data, even with a single overwrite), microwaving the platter (the platter should be removed from the enclosure before doing this), applying sand paper aggressively to the platter, heating the drive in an oven (500 degrees Fahrenheit for 15 minutes? 30 if you want to be extra paranoid, or just leave it in the oven until investigators arrive), or taking a powerful magnet (perhaps from a home/car stereo) to degauss the drive. The platter should be removed first in this method to maximize effectiveness.
+> Note: The Department of Defense (DoD) generally cites a drive wiping policy of 7 passes using random data. Each pass is performed on the entire drive. Other acceptable means of data removal include a single random pass (modern drives make it nearly impossible to recover data, even with a single overwrite), microwaving the platter (the platter should be removed from the enclosure before doing this), applying sand paper aggressively to the platter, heating the drive in an oven (500 degrees Fahrenheit for 15 minutes? 30 if you want to be extra paranoid, or just leave it in the oven until investigators arrive), or taking a powerful magnet (perhaps from a home/car stereo) to degauss the drive. The platter should be removed first in this method to maximize effectiveness.
 
 
 ## Cryptography
@@ -302,12 +311,12 @@ All this being said, there is only one form of unbreakable encryption that will
 
 "The security of the onetime pad cipher is wholly due to the randomness of the key. The key injects randomness into the ciphertext, and if the ciphertext is random then it has no patterns, no structure, nothing the cryptanalyst can latch onto. In fact, it can be mathematically proved that it is impossible for a cryptanalyst to crack a message encrypted with a onetime pad cipher. In other words, the onetime pad cipher is not merely believed to be unbreakable, just as the Vigenère cipher was in the nineteenth century, it really is absolutely secure. The onetime pad offers a guarantee of secrecy: the Holy Grail of cryptography." - Simon Sughes, The Code Book[^35]
 
->Note: An OTP using a CSPRNG (cryptographically secure pseudo-random number generator) still maintains the security of the CSPRNG used, although isn't really an OTP anymore. Instead, it acts as a stream cipher. OTPs are information-theoretically secure, but are not tamper-resistant. Full-disk encryption should only ever be performed using the XTS mode of operation. AES is considered secure against the most powerful attackers in the world, even those with access to quantum computing. If quantum computing is a threat, a 256-bit key should be used. Serpent was the most secure of the 5 AES semifinalists. Rijndael (now known as AES) was the least secure. Rijndael displays a concerningly linear structure, which causes many cryptoanalysts discomfort. However, Rijndael has received the most review of all AES semifinalists and is therefore the best understood. This provides higher assurance that Rijndael is secure than for any other AES semifinalist. ChaCha20 is considered equivalent in security to AES and peforms better on embedded devices. ChaCha20 is also more resistant to improper implementations.
+> Note: An OTP using a CSPRNG (cryptographically secure pseudo-random number generator) still maintains the security of the CSPRNG used, although isn't really an OTP anymore. Instead, it acts as a stream cipher. OTPs are information-theoretically secure, but are not tamper-resistant. Full-disk encryption should only ever be performed using the XTS mode of operation. AES is considered secure against the most powerful attackers in the world, even those with access to quantum computing. If quantum computing is a threat, a 256-bit key should be used. Serpent was the most secure of the 5 AES semifinalists. Rijndael (now known as AES) was the least secure. Rijndael displays a concerningly linear structure, which causes many cryptoanalysts discomfort. However, Rijndael has received the most review of all AES semifinalists and is therefore the best understood. This provides higher assurance that Rijndael is secure than for any other AES semifinalist. ChaCha20 is considered equivalent in security to AES and peforms better on embedded devices. ChaCha20 is also more resistant to improper implementations.
 
 ### Randomness
 Randomness or entropy is the complement to cryptography, or rather a fundamental component. There are two forms of randomness that one would use to generate a One-Time Pad (OTP) message. This randomness can be derived from computational randomness (pseudo random) or pure (theoretical) randomness. Pure randomness is always the goal with the use of OTPs. Unfortunately, there are few ways of achieving this pure randomness. Computational randomness but not theoretical randomness has potential to be broken.
 
->Note: Many (most) modern computers contain hardware true-random number generators (TRNG). To identify if your hardware has such hardware, run `cat /dev/random` on a Linux-based OS. For systems with no TRNG, `cat /dev/random` will produce some amount of output, then produce nothing or produce output slowly. For systems with a TRNG, `cat /dev/random` will produce output continuously, appearing to behave the same as `cat /dev/urandom`. On some systems with TRNGs, `cat /dev/random` will actually produce output faster than `cat /dev/urandom`.
+> Note: Many (most) modern computers contain hardware true-random number generators (TRNG). To identify if your hardware has such hardware, run `cat /dev/random` on a Linux-based OS. For systems with no TRNG, `cat /dev/random` will produce some amount of output, then produce nothing or produce output slowly. For systems with a TRNG, `cat /dev/random` will produce output continuously, appearing to behave the same as `cat /dev/urandom`. On some systems with TRNGs, `cat /dev/random` will actually produce output faster than `cat /dev/urandom`.
 
 For systems with TRNGs, the /dev/random and /dev/urandom devices provide no security difference from each other. However, /dev/urandom performs additional processing on the random data which could help mitigate certain hardware (mis)trust issues, specifically the risk of a backdoored TRNG (while there's no evidence TRNGs have ever been backdoored, this is a concern for some). To increase entropy on GNU/Linux systems, the packages `haveged` and `jitterentropy` can be used along with the boot parameter `random.trust_cpu=off` in the `/etc/default/grub` file. See Madaidan's Linux hardening guide for more details on increasing system entropy.[^36]
 
@@ -361,14 +370,14 @@ To date, Linux Unified Key Setup (LUKS) and Veracrypt[^39] are the two most nota
 - Veracrypt: Primarily container-based encrypt for file storage and plausible deniability with hidden volumes
 - PGP: Used for file-based encryption
 
->Note: Veracrypt can be set to leverage cascading ciphers. Its cascading encryption uses mutually-independent keys.
+> Note: Veracrypt can be set to leverage cascading ciphers. Its cascading encryption uses mutually-independent keys.
 
 #### Offline Password Managers
 Security often comes down to the basics; Make your devices/accounts/services hard to crack. Feds & private forensics companies may be able to allocate ridiculous amounts of computing power against your services to see logs and compromise your accounts, but their brute forcing efforts can be rendered useless.
 
 Consider offline variants of KeePass[^40] for secure password storage, then consider placing the KeePass database inside of a hidden veracrypt. Having a password with an absurd amount of characters such as `dHK&*/4pk_!i??5R=^K}~FU!kxF{fG}*&>oMdRt([);7?=v(e^,ch_n)r()]:&k$D@f4#G"Y\v_5-*i$E[+)"bT*@BF+{hkvn7[B]{qq'[~]3@+-Ju6C(@<]=TEM6a\h$c+:W[k$=;Jy[Un7&~NtvK*{Bn` is enough to stunt any brute force attempt. Cryptographic security can only be as strong as the key being used.
 
->Note: A 20-character random password (letters, numbers, and symbols) provides 132.877 bits of security (compare to 128 bit symmetric encryption keys).
+> Note: A 20-character random password (letters, numbers, and symbols) provides 132.877 bits of security (compare to 128 bit symmetric encryption keys).
 
 >A 29-character random password (letters, numbers, and symbols) provides 192.671 bits of security (compare to 192 bit symmetric encryption keys).
 
@@ -379,7 +388,7 @@ Consider offline variants of KeePass[^40] for secure password storage, then cons
 ### PIM (Personal Iterations Multiplier)
 PIM is treated as a secret value that controls the number of iterations used by the header key derivation function. So long as PIM is treated as a secret parameter, this increases the complexity that an attacker would have to guess.
 
->Note: Larger-value PIMs also increase the time complexity of attacks, at the expense of time taken to perform password hashing. Most cryptologists would argue that a PIMs should not be treated as a secret parameter (or at least, such secrecy should not be relied on). The user's own password should be the source of security. Password hashing, in general, is a mitigation for users with less-than-secure passwords. As a person who values security against the world's most powerful attackers, one should make a point to not rely on password hashing for security.
+> Note: Larger-value PIMs also increase the time complexity of attacks, at the expense of time taken to perform password hashing. Most cryptologists would argue that a PIMs should not be treated as a secret parameter (or at least, such secrecy should not be relied on). The user's own password should be the source of security. Password hashing, in general, is a mitigation for users with less-than-secure passwords. As a person who values security against the world's most powerful attackers, one should make a point to not rely on password hashing for security.
 
 ## Obscurity
 Security professionals will often preach that security through obscurity is an inadequate method of security and should never be a way of addressing your current threat model. The original basis is the distinction "security through obscurity" vs "security by design," often cited as "Kerkhoff's Principle," which concludes a secure cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Kerckhoff's Principal[^] is sometimes cited in terms of Shannon's Maxim[^]: "One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them," or more simply "The enemy knows the system." With the maxim in mind, "security though obscurity" is specifically a cryptographic principal which has been extended to include any system designed with security. It is not discouraged to use security through obscurity. However, it is discouraged to rely on security through obscurity instead of relying on security by design. Obscurity can be used as an additional layer, but security should be guaranteed by the design, with obscurity used only as a padding against unforeseen vulnerabilities.
@@ -437,7 +446,7 @@ Limit the use of these Cellular protocols with the following setting alteration:
 
 Every introduced system creates a larger fingerprint and attack vector, ultimately leading to more trust in more systems and services. The most anonymizing and secure operations require minimal architecture and physical security.
 
->Note: Cellular radio modules lack randomization, rendering mobile devices inadequate for anti-forensics. This has been a pain point to many operations and has often been the sole cause of de-anonymization.
+> Note: Cellular radio modules lack randomization, rendering mobile devices inadequate for anti-forensics. This has been a pain point to many operations and has often been the sole cause of de-anonymization.
 
 ## Automated Shutdown Procedures
 Depending on your threat model, not all operations can be conducted from a coffee shop. There are an increasing amount of cameras, and facial recognition technology is already being deployed, along with license plate scanners at every street light. If operations are sensitive and must be conducted from the same location consistently, preparation should always lean towards the worst-case scenario.
@@ -546,7 +555,7 @@ Hypothetically, if the algorithm/hash combination is known by the attacker, here
 
 "Whether they choose to encrypt with AES, Serpent, Twofish or any other single algorithm, the speed of the attack will remain the same. Attacks on cascaded encryption with two algorithms (e.g. AES(Twofish)) work at half the speed, while cascading three algorithms slows them down to around 1/3 the speed."
 
->Note: VeraCrypt does not keep encryption/hashing algorithms secret. Keeping such information secret would break the functionality of VeraCrypt (unless the user were to enter such information on every boot, comparably to how PIMs work). An attacker will never need to attempt multiple combinations. They will simply need to attempt cracking a single, different, algorithm.
+> Note: VeraCrypt does not keep encryption/hashing algorithms secret. Keeping such information secret would break the functionality of VeraCrypt (unless the user were to enter such information on every boot, comparably to how PIMs work). An attacker will never need to attempt multiple combinations. They will simply need to attempt cracking a single, different, algorithm.
 
 Leveraging Veracrypt:
 1. Generate keyfiles: `veracrypt --create-keyfile`
@@ -572,7 +581,7 @@ The traditional methods of interfacing with the internet stand to be the most se
 
 For those who still require the use of wireless technology in their daily lives, consider the option of airgapping and utilizing a wireless dongle when necessary. Radio transmissions are only allowed when your device powers the USB wireless dongle. If hardware emitting signals cannot be physically removed from the device, consider implementing faraday cages. ([See EMF Shielding section](#emf-shielding))
 
->Note:
+> Note:
     Wireless drivers have been used as a means of system compromise in the past.
 
 Once the device is ready to be shutdown, simply pull the dongle from the device, and there you have a physical killswitch for wireless technology. Not only is time reduced for remote exploitation, but inherent device identifiers with the built-in chipset are removed.
@@ -603,7 +612,7 @@ Every intricacy added for security reduces operation uptime and as a result, pro
 
 Your operations and system must remain accessible despite such intense OPSEC precautions. Instead of compromising on security, consider implementing automation. Simple scripts can reduce the effort needed while keeping nested layers of cryptographic solutions. For instance, create a function for mounting your encrypted drive, closing out an encrypted volume, and the "when things get out of hand" function where files should undergo the process of secure deletion.
 
->Note: As previously noted, secure deletion is generally impossible on SSDs. Also, any bad sectors on a drive (SSD or HDD) cannot be securely erased by software. Such bad sectors must be erased physically. Kali and Parrot include a LUKS "nuke" feature which erases the LUKS headers. This can be used to ensure an encrypted drive cannot be decrypted, even if your password can be broken. This feature can also be installed on any Linux-based OS. Installation of the LUKS nuke feature may conflict with Secure Boot on OSs which don't support it by default.
+> Note: As previously noted, secure deletion is generally impossible on SSDs. Also, any bad sectors on a drive (SSD or HDD) cannot be securely erased by software. Such bad sectors must be erased physically. Kali and Parrot include a LUKS "nuke" feature which erases the LUKS headers. This can be used to ensure an encrypted drive cannot be decrypted, even if your password can be broken. This feature can also be installed on any Linux-based OS. Installation of the LUKS nuke feature may conflict with Secure Boot on OSs which don't support it by default.
 
 With the Bourne Again Shell (BASH) built into GNU/Linux systems, you can create simple functions that will perform these tasks. ([See Appendix A](#appendix-a))
 
@@ -779,7 +788,7 @@ Fortunately, amnesiac solutions are growing. One can run TAILS with the HiddenVM
 
 If a live USB with minimal processing power is not your niche, consider running a hardened base OS such as PlagueOS, to act as a hypervisor that runs amnesiac virtual machines such as Whonix. If the option is taken to avoid live boot, the hardware specification becomes more important. First off, it would be in your best interest to use at least 16GB of RAM. Secondly, consider using one SSD and one HDD. The HDD will be used to hold files, while the SSD is used for facilitating performance for the host OS. As previously stated, HDDs can be wiped by degaussing or overwriting physical sectors while this should be assumed an impossibility for an SSD. Each VM on the host should have a primary function; separate cases and even processes should have separate VMs. For the more technical, sandboxing applications can be used to add nested layers of security. Consider using a sandboxed profile[^60] for your virtualization software, whether it be KVM[^65] or VirtualBox[^66]. Inside the VM, use sandboxing to isolate your processes.
 
->Note: Amnesiac computing is highly advised for journalists with state targets on their back. Most malware will not be able to persist through different sessions, and often they will have to interact with hostile platforms and networks.
+> Note: Amnesiac computing is highly advised for journalists with state targets on their back. Most malware will not be able to persist through different sessions, and often they will have to interact with hostile platforms and networks.
 
 If a mobile device is deemed a necessity, leverage GrapheneOS on a Google Pixel. Encrypt all communications through trusted services or peer-to-peer (P2P) applications like Briar.[^67] Route all device traffic through TOR with the use of Orbot. Keep the cameras blacked out with electrical or gorilla tape. The concept of treating all signals as hostile should be emphasized here as the hardware wireless chipset cannot be de-soldered. Sensors and microphones can successfully be disabled, but the trend with smaller devices is that they run as a System on a Chip (SoC). In short, multiple functions necessary for the system to work are tied together in a single chip. Even if you managed not to fry the device from the de-soldering process, you would have gutted the core mechanisms of the system, resulting in the newfound possession of a paperweight.
 
@@ -942,6 +951,7 @@ Donations to support related projects under `0xacab.org/optout/`` are welcome wi
 [^30]: The Hitchhikers Guide to Online Anonymity (Browser Hardening) - https://anonymousplanet.org/guide.html#appendix-v1-hardening-your-browsers
 [^31]: DuckDuckGo - https://duckduckgo.com
 [^32]: Searx instances - https://searx.space/
+https://github.com/benbusby/whoogle-search
 [^33]: TAILS - https://tails.boum.org
 [^34]: Drive Destruction - https://anonymousplanet-ng.org/guide.html#how-to-securely-wipe-your-whole-laptopdrives-if-you-want-to-erase-everything
 [^35]: Singh, S. (2000). The Code Book: The Secret History of Codes and Code-Breaking - https://3lib.net/dl/1314297/2c09dd