The number that sticks with me is zero. Zero clicks. A malicious WebP image — just sitting in a folder, minding its own business — could compromise a device the moment the operating system decided to render a thumbnail of it. Not when you opened it. When the file manager glanced at it.
CVE-2023-4863. The libwebp heap buffer overflow. That one was everywhere — Chrome, Firefox, Electron apps, pretty much anything that decoded WebP images. And the delivery mechanism in a lot of cases was just... the file being present.
Daniel wrote in with a whole thing about this exact anxiety. He's looking for a very specific AI platform, finds an APK on GitHub, downloads it, and then has that moment — the pause before disabling device security, followed by the voice that says, "Is it already too late?" He wants to know what actually happens from the moment a potentially compromised file lands on a filesystem. Whether the old Linux assumption — that root escalation requires an authenticated user — is actually a safe thing to rely on. Whether there's a rough heuristic for matching an operating system to a file type, so you know when passively downloading something is already a significant vector. What the ideal practice would be, even if nobody actually does it. And whether there are sandboxing tools on Linux, Windows, and Android that don't require spinning up a full virtual machine.
That's a lot of ground. And I want to be careful here, because the easy version of this episode is "don't download sketchy files" and the slightly more useful version is "here's why that advice is incomplete." The gap Daniel's describing — between "I downloaded this" and "I know what this did" — that gap is real, and it's structural. The operating system is doing things to that file before you've made any decision about it.
So let's start with the moment of download itself. What actually happens the instant that file hits the filesystem?
The first thing to understand is that "passive presence" is a myth. A file sitting on disk is not inert. The filesystem writes metadata — timestamps, permissions, extended attributes. Then the desktop environment notices there's a new file. And depending on what kind of file it is, the desktop environment may decide to parse it.
Parse it. Before you've clicked anything.
Before you've clicked anything. On Windows, Explorer has a preview pane and thumbnail generators. If you download a PDF, Explorer will render a thumbnail of the first page. If you download an image, it generates a thumbnail. If you download a document, the preview handler may extract text for the preview pane. All of that requires actually reading the file contents and passing them through parsing libraries. On Linux, GNOME and KDE do the same thing — gdk-pixbuf for images, ffmpegthumbnailer for video, various document thumbnailers. On Android, MediaStore indexes new files, and the thumbnail daemon parses media files to build its database.
So the file isn't just sitting there. It's being read, parsed, and interpreted by system components that run with more privileges than you'd like.
Right. And here's where the zero-click thing stops being a horror movie and becomes an engineering problem. Those parsing libraries are written in C and C++. They handle untrusted input from the internet. And they have bugs. The libwebp one — that was a heap buffer overflow in the Huffman coding decoder. A crafted WebP image could write past the bounds of a buffer, which in the right conditions means arbitrary code execution. The file just had to be decoded. And decoding happens automatically when the thumbnailer runs.
So you download a picture of a cat that is not a picture of a cat, and the act of your file manager showing you the icon is enough.
In the worst case, yes. Now, I want to be precise about how often this actually happens in the wild. Zero-click exploits in parsing libraries are not common. They're expensive to develop, they get patched quickly once discovered, and they're typically used in targeted attacks — journalists, activists, dissidents. The libwebp one was discovered by Citizen Lab and Google's Threat Analysis Group, and it was being actively exploited at the time. But the point isn't that every PNG you download is a landmine. The point is that the line between "I didn't open it" and "it ran" is not a line the user controls.
Daniel mentioned Stagefright, which is the older Android version of this. That was 2015, and it was a whole family of vulnerabilities in the media parsing engine. A malicious MMS message — just receiving it, not opening it — could compromise the phone.
Stagefright was the one that woke a lot of people up, because Android's media stack would automatically parse incoming multimedia messages to generate notifications and previews. The phone processed the file before the user even knew it existed. And Stagefright was a mess — multiple CVEs, multiple patches, and the carriers were slow to push updates. It took years to clean up.
So the first misconception to kill is "if I don't open it, I'm safe." The file gets processed by the system regardless. Now, Daniel's second question — the Linux assumption. He says the assumption has long been that a properly controlled Linux system limits root escalation to authenticated users. Is that a safe mechanism to rely on?
I'd say it's a reasonable default and a terrible guarantee. Let me unpack that. On a traditional Linux system, the permission model says that a process running as an unprivileged user cannot do things that require root — writing to system directories, loading kernel modules, changing firewall rules. To escalate, you either need to authenticate with sudo or exploit something. The assumption is that the "something" is rare and gets patched.
But user namespaces changed the calculus.
User namespaces changed the calculus. The unprivileged user namespace feature lets an unprivileged process create a namespace where it appears to be root — inside that namespace. It can mount filesystems, change ownership, do all sorts of things that look like root activity, but confined to the namespace. The problem is that the kernel code implementing namespaces has bugs. And those bugs have repeatedly allowed a process to break out of the namespace and gain real root on the host.
Give me an example.
CVE-2022-0185 was a heap overflow in the legacy filesystem context handling. An unprivileged user could exploit it through a namespace to get root. CVE-2023-0386 was an overlay filesystem bug — same story, unprivileged user, namespace trick, root on the host. Neither required authentication. Neither required sudo. The attacker just needed code execution as a normal user, which is exactly what a malicious file gives you if it exploits a parser.
So the "authenticated user" boundary is doing less work than people think. The attacker doesn't need to authenticate as root. They just need to be any user, and then they use a kernel bug to jump the fence.
And there's a deeper point here. Even without any kernel bug, an unprivileged process that gets code execution on your Linux machine can do enormous damage without ever becoming root. It can read your SSH keys. It can read your browser cookies. It can read your cloud credentials. It can modify your shell configuration so that the next time you run a command, it runs something else. It can exfiltrate your files. Root is the cherry on top; the sundae is already yours.
That's the knock-on effect Daniel's getting at, I think. The question isn't just "can it get root?" It's "what can it do with the privileges it already has?" And for a typical desktop user, the answer is: everything that matters.
Your documents, your photos, your saved passwords, your browser session, your email. All of that lives in your user directory, readable by any process running as you. So even if the Linux permission model works perfectly and the attacker never escalates, the compromise is already complete from the user's perspective.
Which brings us to the heuristic question. Daniel wants a rough way to match an operating system to a file type, to know when passive downloading is already dangerous. Is there a clean rule of thumb?
There's a decent one. The question to ask is: what does this operating system parse automatically, without asking me? And the answer varies by platform. On Windows, the high-risk types are things Explorer and Office parse on their own — dot lnk shortcut files, PDFs, Office documents, SVGs. A dot lnk file is nasty because Explorer will resolve the icon and the target path just by displaying the file. SVG is nasty because it can contain scripts, and if anything renders it with a browser engine, that script runs.
On Android?
On Android, the high-risk types are APKs and DEX files, because the package manager and the runtime parse those. But also media files — images, videos, audio — because MediaStore and the thumbnail daemon index them. And documents if you have a document provider installed. The Stagefright lesson applies: anything the system will generate a preview for is a potential vector.
And on Linux?
On Linux, dot desktop files are the sneaky one. A dot desktop file is a launcher definition — it specifies an application to run and arguments to pass. If a file manager displays it, it may parse the contents to show the icon and the name. And if the file manager is configured to trust dot desktop files, double-clicking it runs whatever command it specifies. But even passively, the thumbnailer may parse it. SVGs are high-risk on Linux too, because gdk-pixbuf and other libraries render them. PDFs, same story. Anything with a thumbnailer.
So the heuristic is: know your platform's default parsers. If the file type is something your OS renders, previews, indexes, or thumbnails automatically, passive download is already past the point of "safe."
And the corollary: if you want to be safe about a suspicious file, don't just avoid opening it. Avoid letting the OS see it. Download it somewhere that doesn't trigger the thumbnailer, or better yet, somewhere that isn't your real filesystem at all.
Which leads to the third question. The ideal practice. Daniel's guess is that it's something like downloading in a sandbox environment, and he's right — but he also correctly notes that almost nobody does it day to day.
The gold standard is a disposable virtual machine. Snapshot it, download the file, inspect it, and if anything goes wrong, roll back the snapshot and delete the VM. The problem is the overhead. You need the VM software installed, you need a disk image, you need to boot it, you need to wait. For a one-off APK from GitHub, that's a lot of friction. And friction is the enemy of security practice.
Security that requires you to be a full-time sysadmin is security that doesn't happen.
Right. So the practical question is: what's the middle ground? What gives you most of the isolation without the VM overhead? And the answer is different on each platform.
Let's go through them. Linux first.
On Linux, there are two main tools that matter. Firejail is the older one — it's a SUID sandbox that uses namespaces, seccomp-bpf filters, and capability dropping to confine a process. You run "firejail firefox" and Firefox runs in a sandbox where it can't see your real home directory, can't access the network unless you allow it, can't touch the rest of the filesystem. It's not a VM — it's the same kernel, but the process is heavily restricted.
And Firejail has had its own problems.
It has. Firejail has had privilege escalation CVEs, because it's a SUID binary and SUID binaries are a giant target. If the SUID helper has a bug, an attacker can exploit it to get root. So Firejail is better than nothing, but it's not a guarantee. The more modern tool is Bubblewrap, which is what Flatpak uses. Bubblewrap is unprivileged — it uses user namespaces to create the sandbox, so there's no SUID binary to attack. It's much smaller, much simpler, and the attack surface is correspondingly smaller. Flatpak apps run in Bubblewrap sandboxes by default.
So on Linux, the practical recommendation is: use Flatpak for applications you don't fully trust, and use Bubblewrap directly if you want to sandbox a one-off binary.
That's a reasonable starting point. Bubblewrap is available on most distros, and it's simple enough to script. You can create a sandbox with no network access, a read-only view of the filesystem, and a temporary home directory, then run the suspicious file inside it. If it's malicious, it sees an empty sandbox and can't phone home.
Windows?
Windows has Windows Sandbox, which is built into Windows 10 and 11 Pro and Enterprise — not Home. It's a lightweight disposable VM that boots in seconds, runs the file, and when you close it, the entire VM is discarded. It's actually really good. The catch is the Pro/Enterprise requirement, which locks out a lot of home users.
And for Home users?
Sandboxie-Plus is the third-party option. It does application sandboxing via filesystem and registry virtualization — the sandboxed app thinks it's writing to the real filesystem, but all writes go to a sandbox folder, and when you close the sandbox, you can delete everything. It's not as strong as a VM, because it's the same kernel and the same user account, but it blocks persistence and most file-based attacks.
And Android?
Android is interesting because the OS already sandboxes apps from each other. Every Android app runs in its own sandbox with its own user ID. The problem is that the sandbox is designed to protect the system from the app, not really to protect you from a malicious app. A malicious APK that you install gets access to whatever permissions you grant it, and the Android permission model is... generous with user data.
So installing a suspicious APK is already past the point of no return.
Pretty much. Once you install it, it runs with its permissions, and on a stock Android device, there's not much you can do to contain it further. That's where work profiles come in. Island and Shelter are apps that create a work profile — a separate user profile on the same device — and let you install apps into that profile. The apps in the work profile can't see your main profile's data. They have their own storage, their own contacts, their own everything. If the suspicious APK turns out to be malicious, you delete the work profile and everything goes with it.
And GrapheneOS takes this further.
GrapheneOS is a hardened Android fork that does something really clever with Google Play Services. On a normal Android phone, Play Services runs with privileged access — it's a system app with special permissions. On GrapheneOS, you can install Play Services as a regular app in its own sandbox, with no privileged integration. It works for most things, but it can't do the deep system-level stuff that Play Services normally does. That's a security win, but it's a niche option — you need a Pixel device and the willingness to run a custom OS.
So the landscape is: Linux has Bubblewrap and Flatpak, Windows has Windows Sandbox and Sandboxie-Plus, Android has work profiles and GrapheneOS. None of them are VMs, none of them are perfect, and all of them reduce risk without eliminating it.
The tradeoff is real. Firejail had escape CVEs. Windows Sandbox requires Pro. Work profiles still share the kernel with the main profile, so a kernel exploit in the sandboxed app could theoretically break out. The gap Daniel described — between download and certainty — that gap is not closable with current consumer OS design. It's a structural property of how filesystems, parsers, and sandboxes interact.
And there's a deeper point about antivirus. Daniel mentioned that most people don't have antivirus on their phones, himself included. But even on desktop, antivirus is not a great answer to this problem. Signature-based detection looks for known malware. A zero-click exploit in a parsing library is, by definition, not known at the time it's used. The antivirus can't flag what it hasn't seen.
Antivirus is reactive. It's good at catching the mass-market malware that's been circulating for weeks. It's bad at catching the thing that was developed for a specific target and used once. And the zero-click parser bugs are exactly the kind of thing that gets used in targeted attacks.
So if the file is malicious and novel, the antivirus won't help. If it's malicious and old, the OS has probably already parsed it before the antivirus got a look.
Which is why the sandbox approach is the right instinct. Don't try to detect the bad file. Assume it might be bad and contain it from the start.
Let me ask you something. The whole framing here has been about what the OS does without asking. Thumbnail generation, preview panes, indexing. Is there a way to just... turn all that off? Make the OS stop parsing files until you explicitly ask it to?
Partially. On Windows, you can disable the preview pane and thumbnail caching, and you can turn off indexing for specific folders. On Linux, you can disable thumbnailers in the file manager settings, or use a file manager that doesn't generate thumbnails. On Android, you can't do much — MediaStore is going to index media files, and there's no user-facing switch to stop it. But even where you can turn it off, you're fighting the defaults. The OS wants to show you thumbnails and previews because that's what users expect. The convenience is the vulnerability.
Which is the uncomfortable conclusion. The gap between download and certainty is not an accident of implementation. It's a feature of the design. The OS parses files automatically because that's what makes the experience feel responsive and rich. Closing the gap would mean giving up thumbnails, previews, instant indexing — the things that make a modern desktop feel modern.
And that's the tension. Security people have been saying for years that automatic parsing is dangerous, and the response from the platform vendors has been to patch the parsing libraries faster, not to stop parsing. Because stopping parsing would be a worse product.
So where does that leave Daniel, standing there with his APK from GitHub and his finger hovering over the security settings?
It leaves him with a decision framework. First, know what your OS parses automatically. Second, if the file type is in the auto-parse category, don't download it to your real filesystem — download it into a sandbox or a disposable environment. Third, if you can't sandbox, at least rename the file to something your OS doesn't recognize, so the thumbnailer doesn't touch it. Fourth, accept that certainty is not available. The best you can do is reduce the blast radius.
The rename trick is clever. A dot APK renamed to dot txt doesn't get parsed by the package manager. It's just a text file as far as the OS is concerned.
It's a cheap hack, and it's not foolproof — some parsers look at file contents, not extensions. But it's better than letting the OS do its default thing.
And for the APK specifically, the Android answer is: don't install it on your real profile. Use a work profile, or a burner device if you have one. The moment you install an APK, you've made a decision that's hard to reverse.
Android's permission model means the app gets what you grant it, but the sandbox means it shouldn't get anything else. The problem is that "what you grant it" often includes a lot. A malicious APK that asks for storage access and network access can exfiltrate your files. A work profile contains that.
There's one more thing I want to pull on. Daniel said "without being alarmist," and I think that's the right register. The realistic picture is: zero-click parser exploits exist, they get used in targeted attacks, and the average person downloading an APK from GitHub is probably not the target of a nation-state operation. But the average person downloading an APK from GitHub is also not in a position to know whether that APK is one of the mass-market malicious ones that are absolutely floating around.
The realistic risk is not the libwebp zero-click. The realistic risk is the APK that's a repackaged legitimate app with a credential stealer added. That's not a zero-click exploit — that's just social engineering with extra steps. And the sandbox approach handles that too, because the credential stealer has nothing to steal if it's in a work profile with no real data.
So the zero-click stuff is the scary edge case, and the mundane malware is the everyday case, and the same practices help with both.
Don't let the scary edge case drive you to paranoia, but don't let the mundane case lull you into complacency. The middle path is: know what your OS does, contain what you don't trust, and accept that the gap is structural.
Let me ask you one more thing, because I think it's the thing Daniel is really circling. He downloads the APK. He has the moment of doubt. Is it already too late? On a stock Android phone, with the file sitting in Downloads, has the damage already been done?
Probably not, in the specific case of an APK. Android doesn't parse APK contents for thumbnails the way it parses images. The package manager parses the APK when you install it, not when you download it. So the passive vector for an APK is lower than for, say, a WebP image. The danger with an APK is at install time, not download time. So if he downloads it and pauses, he's probably fine. The pause is the right moment.
That's actually reassuring. The specific thing he's worried about — the APK — is not the thing that gets passively parsed. The passive parsing risk is more about images, documents, media files.
Right. The APK is dangerous when you install it. The WebP is dangerous when it's downloaded. Different file types, different moments of danger.
So the heuristic has a second axis. Not just "what does the OS parse automatically," but "when does the OS parse this specific type." An APK is an install-time risk. A PDF is a download-time risk on Windows. A dot desktop file is a display-time risk on Linux.
That's the kind of nuance that makes the heuristic useful rather than just scary. You can look at a file type and say: this one is dangerous now, this one is dangerous later, this one is probably fine unless I do something dumb.
Which is a much better place to be than "all files are equally scary and I should never download anything."
The goal isn't to avoid downloading files. The goal is to know what happens when you do.
Hilbert: You're both too optimistic.
Say more.
Hilbert: I worked a six-month contract at a mid-sized regional bank in two thousand three. Officially I was in Endpoint Security. What that meant was I sat in a windowless room re-imaging teller workstations that had been bricked by email attachments. The bank's policy was "just don't open it." Every single week, someone opened it. Or didn't open it, and Outlook's preview pane rendered it anyway. The preview pane was the whole problem. It parsed the attachment to show you the first few lines, and that was enough.
The bank's security policy was defeated by a feature that was on by default.
Hilbert: It was defeated by a checkbox. I finally convinced them to let me disable the preview pane via Group Policy. Push it out to every workstation. That was considered a radical act. The IT director had to sign off on it. People were angry. They wanted their previews back.
But the bricked workstations stopped.
Hilbert: The bricked workstations stopped. I still have the Group Policy Object backup on a Zip disk in my garage. Labeled "PREVIEW KILLER — DO NOT LOSE." I have never been able to throw it away. You never know when you'll need to kill a preview again.
The Zip disk is a nice touch. That's a hundred megabyte disk, if you're lucky.
Hilbert: Two hundred and fifty. The good ones.
Your lived experience is that the passive parsing problem is not a theoretical edge case. It was the main vector at a bank, twenty years ago.
Hilbert: It was the main vector because nobody believed it was a vector. The file just had to arrive. Outlook did the rest. And the antivirus didn't catch it, because the attachment was always something new. The signature updates came on Tuesday. The bricked workstation came on Monday.
That's the reactive detection problem in a nutshell. The antivirus is always a day behind.
Hilbert: There's one more thing. In two thousand one, I downloaded a copy of Winamp from a Russian mirror. Definitely legitimate, I told myself. The download finished, and my computer made a sound it shouldn't have made. I have never trusted file extensions since.
What sound?
Hilbert: Like a floppy drive seeking, but there was no floppy in the drive. And the speakers clicked. Twice.
That's the sound of something running that you didn't ask to run.
Hilbert: That's the sound of me reformatting a hard drive at two in the morning. I don't know what it was. I never found out. But I learned that day that the file extension is a suggestion, not a fact.
The extension is a suggestion, and the OS is going to do what it wants with the contents.
Hilbert: The OS is going to do what it was told to do by whoever built the parser. And the parser was told to be convenient.
Convenience as an attack surface. That's the whole episode in four words.
Hilbert: I'd still have that Zip disk if I were you. You never know when a preview needs killing.
I'll keep that in mind.
The open question this leaves me with: if the gap between download and certainty is structural — if it's built into the way operating systems handle files — what would it take to close it? Would you have to give up thumbnails and previews entirely? Or is there a middle design where the OS asks before parsing anything it doesn't recognize?
The asking is the problem. If the OS asked every time it wanted to render a thumbnail, you'd click "yes" ten thousand times a day and the prompt would become meaningless. The gap might actually be a feature. It's the price of a responsive system.
The price is going up. As AI-generated files and AI-parsed content become more common, the attack surface for passive parsing expands. Every new file type that gets auto-indexed or auto-previewed is a new potential vector. The model that auto-tags your photos is parsing every image. The assistant that summarizes your documents is reading every PDF.
The heuristic isn't "don't download suspicious files." It's "know which file types your OS parses without asking you." And if you don't know, assume the answer is all of them.
That's the note to land on. Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. Email us at show at my weird prompts dot com.
We'll be back soon.
