Daniel sent us this one — he's been installing Linux, staring at those colorful filesystem options during setup, and wondering about two things. First, full disk encryption. What it actually does, where the key lives, whether the performance hit is worth it, and how it compares to BIOS-level or hardware-level disk encryption. Second, those hardware-encrypted external drives with the keypads and physical keys — versus just creating an encrypted software vault yourself. He's basically asking, what's the point of all this fancy encryption if you're not a spy, and when does it stop being a luxury and start being practical?
The timing's interesting on this — I was just reading about Google's new agentic AI widgets for Android, and one of the things that came up in the security discussion was that on-device processing requires strong local encryption if the agent is handling your personal data. It's not just for spies anymore. Let's start with full disk encryption, because there's a lot of confusion about what's actually happening under the hood.
Before we get into it — the prompt mentions the "raw seal commercials" and I just want to confirm that Daniel meant Flex Seal. The liquid rubber in a can. I'm choosing to believe this was a Freudian slip and not a different product entirely.
I'm pretty sure it was Flex Seal, yes.
Because "raw seal" sounds like something you'd find in a medieval apothecary and I was concerned about his purchasing decisions. Alright, full disk encryption. What's actually happening when you check that box during a Linux install?
On modern Linux systems, when you choose full disk encryption, you're almost certainly using LUKS — the Linux Unified Key Setup — which sits on top of dm-crypt, the kernel-level encryption subsystem. What it actually does is encrypt everything on a block device, sector by sector. Every single read from disk gets decrypted in memory, every write gets encrypted before it hits the physical platter or NAND cells. The encryption happens transparently to the operating system once the volume is unlocked.
It's not like a vault within the filesystem. It's the entire filesystem itself that's scrambled.
And this is where the "where does the key live" question gets interesting. The actual encryption key is a master key that's generated randomly during setup. But that master key isn't what you type in. What you provide is a passphrase that unlocks one of potentially eight key slots in the LUKS header. Each slot contains an encrypted copy of the master key. So you could have your main passphrase in slot zero, a recovery key in slot one, maybe a key file on a USB stick in slot two. The LUKS header lives in plaintext at the beginning of the disk — it has to, otherwise the system couldn't prompt you to unlock anything. But the header only contains encrypted copies of the master key. Without a valid passphrase, those encrypted blobs are useless.
This is the part where someone asks, "well, if the header is in plaintext, can't an attacker just brute-force it?" And the answer is...
They can try. LUKS uses PBKDF2 or Argon2 to derive the key from your passphrase. Argon2 in particular is designed to be memory-hard and computationally expensive. On LUKS2 with Argon2id, a single passphrase attempt takes something like one full second of CPU time and a gigabyte of RAM. You're looking at billions of years to brute-force a decent passphrase. The weak point is almost never the cryptography — it's the passphrase quality. If your passphrase is "password123" you're still toast regardless of how fancy the key derivation is.
The cryptographic equivalent of putting a bank vault door on a garden shed and then leaving the key under the mat. But let's get to the performance question, because this is the one that scares people off.
Here's the reality: on any CPU made in the last decade or so, the encryption is handled by dedicated hardware instructions — AES-NI on Intel and AMD chips, or the ARM equivalent. These instructions perform AES encryption and decryption in hardware at speeds that are essentially the memory bandwidth limit. With AES-NI enabled, the overhead for AES-256-XTS, which is the standard mode for LUKS, is typically between zero and three percent for sequential reads and writes. On NVMe drives that can push five to seven gigabytes per second, you might see the overhead creep up to maybe five percent in synthetic benchmarks. But for random I/O — which is what most real-world workloads look like — the difference is basically in the noise.
The "significant speed overhead" concern is, for most people, a ghost.
It's a ghost from the era when encryption was done entirely in software on CPUs that didn't have hardware acceleration. Back in the mid-2000s, yes, you'd notice. Today, your NVMe drive is almost certainly the bottleneck long before AES is. There's an interesting wrinkle: some modern drives compress data internally, and encrypted data doesn't compress well because it looks like random noise. So in some edge cases, encryption can expose that your drive's advertised speeds assumed compressible data. But that's a drive firmware issue, not an encryption issue.
The music industry's loudness war but for storage benchmarks. "Our drive does seven gigabytes per second — asterisk, with highly compressible zeroes, in a temperature-controlled vacuum chamber, during a full moon.
The drive industry does love its asterisks. But the core takeaway is: if you're on hardware from the last eight to ten years, you will not feel full disk encryption in day-to-day use. Your browser will not open slower. Your games will not stutter. Your compile times will be identical.
Alright, so performance isn't the real objection. What about the "why bother if my desktop never leaves my house" argument?
This is where the threat model discussion comes in. If your desktop sits in your home office and you live alone and you're not worried about anyone physically accessing it, then full disk encryption is solving a problem you don't have. But threat models change. You take the computer to a repair shop. You sell it or recycle it someday. Your house gets broken into. Someone with sticky fingers at a LAN party.
Or you die and your family has to go through your stuff and you'd rather they didn't find your extremely detailed spreadsheet ranking every brand of instant ramen.
We all have our secrets. But the more practical angle is: full disk encryption makes decommissioning a drive trivial. Without encryption, securely disposing of a drive requires overwriting it completely — which on modern SSDs with wear leveling and over-provisioning is surprisingly hard to do reliably. With encryption, you just destroy the LUKS header, a couple megabytes at the start of the disk, and the rest of the data is indistinguishable from random noise forever.
That's actually a compelling argument that doesn't require a threat model at all. It's just good data hygiene. The digital equivalent of shredding documents before recycling them.
And it takes thirty seconds instead of hours of multi-pass overwrites that might not even work properly on an SSD.
Now the prompt takes a turn here. Daniel mentions poking around in BIOS settings and seeing boot passwords and encryption options. And then he asks about hardware-level disk encryption — drives that have encryption built into the drive controller itself, sometimes with a physical key. How does that compare to software full disk encryption?
This is where we get into the difference between software-based encryption like LUKS, and what's called SED — Self-Encrypting Drives. SEDs use the OPAL standard from the Trusted Computing Group. The drive controller has a built-in encryption engine that encrypts everything written to the physical media. The encryption key is stored on the drive itself, usually in a protected area of the controller.
The BIOS boot password — is that the same thing?
A BIOS or UEFI boot password is just an authentication check before the firmware hands off to the bootloader. It doesn't encrypt anything. An attacker could remove the drive, plug it into another machine, and read everything. It's the digital equivalent of a "do not enter" sign. Now, some BIOS setups let you set an ATA password on the drive itself, which is different — that password is checked by the drive firmware. And if the drive is a SED, the ATA password can actually be used to encrypt the encryption key.
The hierarchy is: BIOS boot password is theater, ATA drive password is slightly better theater unless paired with actual encryption, and SED is real encryption but done by a black box you don't control.
That last part is the crux of the whole debate. With LUKS and dm-crypt, the encryption is done by open-source code running on your CPU. You can inspect it. The community has audited it. The master key never leaves your system's RAM in unencrypted form, and you control where the key material goes. With a SED, the encryption is done by proprietary firmware in the drive controller. You have no idea if there's a backdoor or if the implementation is correct. In 2018, researchers found that multiple SSD models with hardware encryption — including drives from Crucial and Samsung — had critical implementation flaws. The drives claimed to use AES-256 but the key derivation was broken, or the encryption key was stored in a way that could be extracted, or the password validation could be bypassed entirely. Microsoft actually published guidance after this telling enterprise customers to prefer software encryption over hardware encryption.
The "fancy BIOS encryption options" and the SED checkbox are, generously, a mixed bag. But what about the physical key thing Daniel mentioned? Drives that require you to literally insert a hardware key to decrypt them?
That's a niche within a niche. There are drives that use a physical authentication token — usually a smart card or a USB security key — as a second factor. The drive won't unlock unless the token is present. This is conceptually similar to using a YubiKey to unlock a LUKS volume, which you can absolutely do. The difference is whether the enforcement happens in the drive firmware or in the operating system. And given what I just said about proprietary firmware implementations, I strongly lean toward the OS-level approach. A YubiKey configured with FIDO2 or HMAC-SHA1 challenge-response to unlock a LUKS volume gives you the same "something you have" factor, but the cryptography is happening in auditable software. If the YubiKey is lost or stolen, your passphrase is still protecting the volume — the token is an additional factor, not a replacement.
The physical key approach sounds cooler, though. It has that James Bond energy Daniel mentioned. Sliding a cryptographic key into a slot on your drive chassis.
It absolutely looks cooler. But "looking cool" and "being secure" are only tangentially related. The aesthetic of security is one of the most profitable marketing categories in technology. It's why VPN services can sell you a product by showing you green matrix text and a padlock icon while telling you nothing about their actual infrastructure.
The glockenspiel of corporate approachability strikes again. Alright, let's pivot to the second half of the prompt — encrypted external storage. Those external drives with built-in keypads and physical unlock mechanisms. Kingston makes them. Apricorn, iStorage, a few others. What's the pitch?
The pitch is that you don't need any software on the host computer. The encryption and decryption happen entirely within the drive enclosure. You plug it in, type a PIN on the keypad, and the drive presents itself as a normal storage volume. Unplug it, and it locks automatically. The encryption key is generated on the drive and never leaves it.
The counter-pitch is that you're trusting a proprietary hardware implementation you can't audit.
Which is the same problem as the internal SEDs, but amplified by the fact that these are portable devices you might plug into untrusted computers. A few years ago, some hardware-encrypted USB drives were found to be sending the encryption key to the host computer in plaintext during the unlock process, because the firmware developers apparently didn't understand that USB communication is observable.
That's not a vulnerability. That's a design philosophy of "let's just hope nobody looks.
It's the security equivalent of hiding your house key under the doormat and then posting a sign that says "key is not under the doormat." Meanwhile, the alternative Daniel mentioned is creating an encrypted software volume — a Veracrypt container, or a LUKS-encrypted partition on the external drive, or using something like Cryptomator for cloud storage. The drive itself is just a dumb block device. All the cryptography happens in software you can choose, audit, and update.
What's the actual advantage of the hardware-encrypted drive? There has to be one, or nobody would buy them.
There are a few legitimate use cases. First, platform independence. A hardware-encrypted drive with a keypad works identically on Windows, Mac, Linux, ChromeOS, whatever — it just shows up as a mass storage device. No software to install, no drivers to configure. For someone who moves between operating systems constantly, that's genuinely useful. Second, there's a defense-in-depth argument. A well-implemented hardware-encrypted drive moves the attack surface off the host computer entirely. If the host is compromised with a keylogger, it won't capture the drive's PIN because the PIN entry happens on the drive's own keypad, not through the keyboard.
That's actually interesting. The keypad on the drive itself is air-gapped from the host. A software keylogger sees nothing.
With a software-encrypted volume, your passphrase is typed on the host keyboard, which means a compromised host can capture it. Now, if your host is that compromised, you probably have bigger problems — but it's a real difference in threat model.
What about the wear-leveling keypad thing? I've seen some of these drives where the keypad buttons are clearly going to get shiny and worn over time, revealing which digits are in your PIN.
Some manufacturers have thought about this and use uniform keycaps or randomized keypad layouts on an e-ink display. Others haven't, and yes, you can literally read the PIN off a well-used drive by looking at which keys are worn smooth.
That's not a side-channel attack. That's a front-channel attack with your eyeballs.
The most sophisticated cryptanalysis technique of all: looking at something. But to answer Daniel's core question directly — what are the pros and cons of hardware-encrypted external drives versus doing it in software?
Let's do this systematically. Pros of hardware encrypted drives.
Platform independence — works anywhere without software. Physical PIN entry that's immune to host-based keyloggers. Usually FIPS certified if you're in a regulated industry that requires that. Automatic locking when unplugged — no risk of forgetting to unmount. And some models have tamper-evident or tamper-responsive enclosures that will wipe the key if someone tries to physically open the drive.
Cons of hardware encrypted drives.
You can't audit the implementation. The firmware is rarely updated, and when it is, the update process is often arcane or nonexistent. They're significantly more expensive — a hardware-encrypted Kingston IronKey might cost four to five times what an equivalent-capacity standard external SSD costs. And if the keypad or controller fails, your data is gone — you can't just pull the drive out of the enclosure and decrypt it on another machine, because the encryption is tied to that specific controller.
That last one is the nightmare scenario. The drive works fine, the enclosure's USB port gets physically damaged, and now you have a perfectly good NAND chip full of data you can never read again.
Whereas with a standard external drive that has a Veracrypt or LUKS volume on it, if the enclosure fails, you pull the drive out, put it in a new enclosure, and unlock it with your passphrase. The encryption is portable.
Pros of software encryption on external storage.
Auditable, open-source implementations. Portable across enclosures. Usually free — Veracrypt, LUKS, Cryptomator, they cost nothing. You can use the same tools and passphrases across all your storage. You can back up just the LUKS header and have disaster recovery options. You can use hardware tokens like YubiKeys for second-factor unlock.
You need software on the host, which means you can't use it on locked-down machines. Your passphrase is typed on the host keyboard, so a compromised host can capture it. You have to remember to unmount properly — unplugging without unmounting won't necessarily corrupt an encrypted volume, but it's not great practice. And there's a small learning curve — creating a Veracrypt volume isn't hard, but it's more steps than just typing a PIN on a keypad.
The decision tree really comes down to: do you need to access this data from machines you don't control, or do you work in a regulated industry that requires FIPS certification? If yes, hardware encryption might be worth it despite the trust and cost issues. If no, software encryption is cheaper, more auditable, and more recoverable.
That's the executive summary. And I'd add one more consideration: if you're using cloud storage as your primary backup, software encryption is really your only option for end-to-end protection. You can create a Veracrypt container and store it in Google Drive or Dropbox — it's just a file as far as the cloud provider is concerned. They can't see inside it. You can't do that with a hardware-encrypted drive sitting on your desk.
Which brings us to an interesting point the prompt doesn't explicitly ask but implies: is there a middle ground? Something that gives you the platform independence of a hardware solution with the auditability of software?
There are some interesting projects in this space. Heads, an open-source firmware project, can do measured boot and TPM-based disk unlock on laptops. You can use a YubiKey as a physical unlock token for LUKS volumes — plug it in, the volume unlocks, unplug it, the volume locks. It's not quite as seamless as a keypad drive, but you get the physical factor without the proprietary black box.
The TPM angle is worth exploring, since the prompt mentioned BIOS-level encryption options. A TPM — Trusted Platform Module — is a hardware chip on the motherboard that can securely store keys and perform cryptographic operations. How does that fit into the disk encryption picture?
TPMs are fascinating. The way they're typically used with disk encryption is something called "measured boot" or "trusted boot." The TPM measures the integrity of the boot process — the firmware, the bootloader, the kernel — and only releases the disk encryption key if nothing has been tampered with. If someone tries to boot from a malicious USB stick or modifies the bootloader, the measurements won't match and the TPM refuses to unseal the key. This lets you do something interesting: disk encryption without typing a passphrase at boot. The TPM holds the key and releases it automatically if the system is in a known-good state. This is how Windows BitLocker works by default on modern machines, and it's how many Linux distributions handle full disk encryption on laptops.
If the TPM releases the key automatically, doesn't that mean anyone who steals the laptop can just turn it on and get access?
That's why TPM-only unlock is usually combined with a PIN. The TPM can be configured to require both a valid system state AND a user-provided PIN before unsealing the key. This is "something you have" — the TPM in that specific machine — plus "something you know" — the PIN. If you pull the drive out and put it in another machine, the TPM is different and the key won't unseal. And the TPM has anti-hammering protections — after a certain number of incorrect attempts, it starts imposing exponentially increasing delays. You can't brute-force a TPM-backed PIN at any practical rate.
This is a well-designed system. And it's the kind of thing that probably exists in Daniel's BIOS settings under some inscrutable name.
The problem is that the BIOS interfaces for configuring TPM-based disk encryption are uniformly terrible. They use terminology that assumes you already know what a Platform Configuration Register is. It's one of those areas where the technology is solid but the user experience is actively hostile.
The UX equivalent of a door that says "push" but has a handle that clearly pulls.
Then there's Secure Boot, which is often confused with disk encryption but is actually a different thing entirely. Secure Boot verifies that the bootloader and kernel are cryptographically signed by a trusted authority. It prevents malware from inserting itself into the boot process. But it doesn't encrypt anything — it just ensures that what you're booting hasn't been tampered with.
Secure Boot plus TPM-based disk encryption is the full stack. Secure Boot ensures nothing malicious runs at boot, the TPM verifies the boot chain integrity, and only then does the disk encryption key get released.
All of this is happening before the operating system even loads the login screen. It's impressive security engineering that most users never think about.
Let me pull us back to something the prompt touches on that I think deserves more attention. Daniel mentions that for his "homework station" that never leaves the house, full disk encryption seems pointless. And I think that's worth interrogating.
The "it never leaves my desk" argument.
Because I think there's a hidden assumption there that physical security is binary — either the computer is in your locked house and therefore safe, or it's in a coffee shop and therefore at risk. But residential burglaries happen. Maintenance people come into your home. Friends of roommates wander through. A pipe bursts and emergency repair people need access. Your house isn't a vault just because you have a front door key.
There's also the repair shop scenario, which is probably the most common way people's data gets compromised. You take your desktop or laptop in because the GPU is acting up, and now some technician you've never met has full access to every file on your machine. Most repair shops are honest, but it only takes one curious technician with time on their hands. And unlike a laptop where you can pull the drive before sending it in, a lot of all-in-one desktops or tightly integrated machines make drive removal a whole project.
The other scenario that gets overlooked is resale and disposal. Most people don't securely wipe drives before selling or recycling computers. They delete their files and assume that's enough. With full disk encryption, you don't need to securely wipe anything. You just destroy the LUKS header or the TPM's stored key, and the drive is cryptographically erased. Even if someone uses forensic tools to recover the raw data, it's all ciphertext.
It's worth noting that this is increasingly relevant as storage densities increase. A four-terabyte NVMe drive can hold an entire life's worth of documents, photos, financial records, and scanned tax returns. The blast radius of losing physical control of that drive is enormous.
Let's talk about the passphrase problem, because this is where a lot of the practical objections live. If you enable full disk encryption, you now have to type a passphrase every time you boot. That's friction. And if you make the passphrase simple enough to type easily, it's weak. If you make it strong, it's annoying.
This is where TPM integration really shines. On a modern laptop with a TPM, you can set up the system so that the TPM unseals the key automatically as long as the boot chain is intact. You never type a passphrase at boot — the system just starts. But if someone tries to boot from external media or tampers with the bootloader, the TPM refuses and falls back to a recovery passphrase. So the normal user experience is identical to not having encryption, but the protection is still there. There's a subtlety about suspend versus hibernation, though. When a system is suspended to RAM, the encryption keys are still in memory. An attacker with physical access and the right equipment can potentially extract keys from RAM — this is the classic cold boot attack. Hibernation writes memory to disk, which on an encrypted system means the hibernation image is encrypted. So if you're really paranoid, you configure the system to hibernate instead of suspend.
The cold boot attack is one of those things that sounds terrifying in a security paper and is almost never relevant in practice unless you're being targeted by a nation-state. It requires spraying the RAM chips with liquid nitrogen and reading them out with specialized hardware in the minutes after power loss.
For the threat model Daniel's describing — protecting personal data from opportunistic access — cold boot attacks are not the concern. The concern is someone grabbing the powered-off machine and trying to read the drive.
Alright, let me shift to something practical. If someone listening wants to set up full disk encryption on a Linux system they're installing today, what should they actually do? Walk me through the real options.
For a typical desktop or laptop install, most major distributions now offer full disk encryption as a checkbox in the installer. Ubuntu, Fedora, Debian — they all have an "encrypt my disk" option. What happens behind the scenes is they create a small unencrypted boot partition for the bootloader and kernel, then encrypt the rest of the disk with LUKS. You set a passphrase during install, and that's what you'll type at boot. For TPM-based unlock, there's a tool called systemd-cryptenroll that makes this relatively straightforward. You enroll the TPM with a PCR policy — that's the set of Platform Configuration Registers that define what a "trusted" boot state looks like — and then the TPM will handle key release. Adding a YubiKey as a second factor is also supported through systemd-cryptenroll with FIDO2.
Systemd really has absorbed everything, hasn't it. What's next, systemd-bakery? systemd-emotional-support?
The systemd project has certainly been ambitious. But cryptenroll is well-designed. It handles the complexity of TPM policies and FIDO2 enrollment without requiring you to understand every register and algorithm.
For external drives? If someone wants to create an encrypted external SSD that works across different Linux machines?
The simplest approach is to format the external drive with LUKS. Plug it in, run cryptsetup luksFormat on the partition, set a passphrase, then cryptsetup open to unlock it and create a filesystem inside the encrypted container. After that, plugging the drive into any Linux machine will prompt for the passphrase — most desktop environments handle this automatically now through udisks.
If you need cross-platform compatibility with Windows and Mac?
Veracrypt is the standard answer. Create a Veracrypt volume on the drive, and you can mount it on all three platforms with the Veracrypt software. The downside is you need Veracrypt installed everywhere you want to access the drive. The upside is the implementation has been audited and it uses strong, well-understood cryptography.
What about the cloud storage angle Daniel mentioned? Creating an encrypted vault and storing it in Google Drive?
Cryptomator is purpose-built for this. It creates an encrypted vault where each file is individually encrypted, so changes to one file don't require re-uploading a monolithic container. It's designed for cloud sync — the encryption is transparent to the sync client. You get end-to-end encryption with the convenience of cloud storage. Veracrypt containers work too, but they're a single large file, so changing one document means re-syncing the entire multi-gigabyte container — which becomes impractical for large vaults. Cryptomator's per-file encryption is the smarter approach for cloud use.
Let me circle back to something we touched on earlier that I want to make explicit. The prompt asks about "probably unnecessary encryption that people might nevertheless want to do if you either wanted to feel like James Bond or actually have a genuine need." And I think the genuine need part is more common than people realize.
The threshold for "genuine need" has shifted. Twenty years ago, full disk encryption was for dissidents and corporate security officers. Today, your laptop contains your entire financial life, your private conversations, your family photos, your medical information, your password manager database, and probably cached copies of every sensitive document you've ever opened. The blast radius of losing an unencrypted laptop isn't "someone might read my email" — it's "someone has a complete dossier on my life.
The cost of enabling encryption has dropped to essentially zero. No performance penalty, no real usability penalty if you set up TPM unlock, and it's a checkbox in the installer. The cost-benefit ratio has completely inverted.
It's one of those rare cases in security where the secure option is also the convenient option. You check a box during installation and then forget about it. The encryption is transparent.
The exception being if you forget your passphrase. That's the one failure mode where encryption is unforgiving. There's no password reset email for LUKS.
That's important to emphasize. Full disk encryption means full data loss if you lose the passphrase and all key slots. There is no backdoor, no recovery mechanism, no customer support that can help you. If you set up full disk encryption, you need a passphrase management strategy. Write down a recovery key and store it somewhere physically secure. Print it on paper. Put it in a safe deposit box. Give a copy to a trusted family member who lives in a different city.
The analog backup for the digital lock. A piece of paper in a drawer somewhere.
It feels low-tech, but it's resilient. Fires don't destroy safe deposit boxes. Hackers can't exfiltrate a piece of paper. And if you're incapacitated, your family can still access your data if they need to — assuming you've planned for that.
Which is a whole other conversation about digital legacy and estate planning that we should probably have another time. Alright, let's synthesize this. If Daniel — or any listener — is setting up a Linux system and staring at the encryption checkbox, what's the recommendation?
Check the box. Use the default LUKS setup. Set a strong passphrase — and by strong I mean a passphrase, not a password. A sequence of four or five random words is both more secure and easier to type than a shorter string of random characters. Write the passphrase down and store it securely. If your hardware supports it, consider enrolling a TPM post-install for passwordless boot.
For external drives?
If you're staying in the Linux ecosystem, LUKS on the external drive. If you need cross-platform, Veracrypt. If it's for cloud storage, Cryptomator.
Hardware-encrypted drives with keypads?
Only if you have a specific need for platform independence on machines you don't control, or if you're in a regulated industry that mandates FIPS validation. For everyone else, the trust and cost issues outweigh the convenience.
The prompt's James Bond scenario is basically: if you're not James Bond, you probably don't need a hardware-encrypted keypad drive. And if you are James Bond, you definitely shouldn't trust a proprietary black box from a consumer electronics manufacturer.
Q branch would roll their own implementation anyway.
MI6 is not buying Kingston IronKeys off Amazon.
Although that would be a very different kind of Bond film. "James, this drive has a CE mark and mixed reviews on Trustpilot. Use it wisely.
"The three-star reviews mention occasional disconnects during large file transfers, double-oh-seven. Do be careful.
And now: Hilbert's daily fun fact.
Hilbert: In the nineteen fifties, the naked mole rat was briefly believed to be extinct on Réunion Island after a mislabeled museum specimen from East Africa was mistaken for a local species, sparking a two-year taxonomic panic before researchers realized the animal had never lived there in the first place.
They panicked about losing something they never had.
The most efficient kind of crisis. Nothing actually happened.
This has been My Weird Prompts. Our producer is Hilbert Flumingtop. You can find every episode at myweirdprompts dot com. If you enjoyed this, leave us a review — it helps other people find the show.
We'll be back next week with another prompt.
