Windows reports the path of every file touched on the machine, and Microsoft calls it an undocumented feature

Twenty six years of an interface nobody treated as a boundary

Every mainstream operating system lets a program ask to be told when files change. Text editors use it to notice a file moved under them, backup tools use it to know what to copy, and search indexes use it so they do not have to walk the disk. The interfaces are old: ReadDirectoryChangesW arrived with Windows 2000, twenty six years ago; inotify landed in Linux 2.6.13 in 2005; macOS got File System Events with Leopard in 2007; Android wrapped inotify as FileObserver in 2008.

Researchers at the Institute of Information Security at Graz University of Technology have now shown what those notifications leak, in a paper to appear at ACM CCS in November. The answer is that you do not need to read a file to learn a great deal from the fact that somebody else touched it.

The sharpest case is Windows. A watch placed on the root of C: reports filesystem events from across the whole machine, with filenames, regardless of whether the watching user can read the files involved. Because Firefox creates directories named after the sites a user visits, that was enough to identify which of the top 1,000 websites another user was browsing, in real time, with an F1 score of 97.8 per cent.

What that does not establish. It does not establish remote exploitation: every attack here needs local code running as another user on the same machine, which the authors describe as "a local, cross-user attacker (think of a compromised user/system service), or a supply-chain-attacked package". It does not establish that file contents leak, because they do not: only names, paths and timing. It does not establish exploitation in the wild, and the authors report none. And it does not establish that every system is equally exposed, because macOS came out of the study leaking the least.

What it does establish is that four operating systems shipped a metadata channel that crosses user boundaries, that it has been there for between eighteen and twenty six years, and that only one of the four vendors has treated the finding as a defect.

What a notification carries

A file notification is not the file. It is an event saying something happened to a path: opened, written, modified, deleted, moved. The contents stay unknown.

That sounds thin until you consider what a path and a timestamp are. A path is chosen by an application to describe what it is doing, and applications are helpful. Firefox names a storage directory after the site. WhatsApp separates sent from received and images from documents by folder. A password prompt is a specific binary being executed at a specific moment. None of those names is a secret in itself, which is exactly why nobody guarded them.

Timing does the rest. The interval between two events is the interval between two actions, and inferring behaviour from inter-event timing is an old and very well developed craft, running from keystroke timing work in 2001 through to studies published this year.

The four demonstrations

Keystroke timing on Linux. Watching /dev/input produces events when input device files are accessed, without the watcher having any read access to those files. The events do not say which key was pressed. They say when, and the gaps between keystrokes carry information that two decades of published work knows how to use.

A password prompt you can get in front of. On KDE Plasma under Wayland, watching /usr/bin/pkexec tells an attacker that an authentication dialog is about to appear. Knowing that in advance is the hard part of a user interface redress attack: you can put your own dialog up first. KDE's response, quoted by the researchers, is that focus stealing prevention "isn't designed to be a security mechanism".

A timeline of somebody's messages on Android. FileObserver bypasses the per application storage view that the FUSE layer presents, so an unprivileged app can watch another app's private media folder. Against WhatsApp, that yields filenames, the folder structure that separates images from documents and sent from received, and event timing about a tenth of a second after a download and decryption finish. The authors describe the result as "a timeline of exactly what and when a user sent and received", including deletions.

Which websites another user is on, in Windows. The root watch on C: reports events system wide with filenames, regardless of permissions. Firefox creates per site directories for local storage, IndexedDB and cache. The paper reports identifying sites from the top 1,000 with an F1 score of 97.8 per cent, with examples including wikipedia.org, amazon.de, twitch.tv and mastodon.social.

Four vendors, four answers

The interfaces, their ages and what each vendor did

Platform and interface	Shipped	Status
Windows, ReadDirectoryChangesW and FileSystemWatcher	2000, 26 years ago	No fix. Microsoft calls the behaviour an undocumented feature. A registry policy exists and is off by default
Linux, inotify	2005, 21 years ago	Partially fixed December 2025 as CVE-2025-68788: no access or modify events on special files such as those in /dev
macOS, File System Events	2007, 19 years ago	No fix. Leaks the least of the four
Android, FileObserver	2008, 18 years ago	No fix

The Linux answer is what a fix looks like. The kernel stopped generating access and modify events for character devices, which is what the files under /dev are, and shipped it across the stable series: 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65 and 6.18.3, credited to Amir Goldstein, Jan Kara, Greg Kroah-Hartman and the kernel security team.

The Windows answer is the one worth arguing about. There is a registry policy, EnforceDirectoryChangeNotificationPermissionCheck, which mitigates the attacks, and Microsoft documented the underlying access check enhancement in April 2025 after a separate report. The policy is disabled by default. So the fix exists, ships in the product, and is switched off unless an administrator knows to look for it, while the behaviour it disables is described as a feature rather than a flaw. The researchers note the response was nominated at the Pwnie Awards this year in the category for the lamest vendor response, which is an opinion rather than a finding, but a widely shared one.

What this is not

Established by the research against not established by it

Established	Not established
Path, event type and timing cross user boundaries on these systems	That file contents are exposed. They are not
Website identification at an F1 score of 97.8 per cent against the top 1,000 sites	That this generalises to browsers other than the one tested
A local attacker, or a compromised package, is enough	Any remote or unauthenticated path
Proof of concept code exists and is published	Any exploitation in the wild. The authors report none
Linux shipped a partial fix in December 2025	That the Linux fix covers every case. The authors call it partial

What to do about it

For most organisations this is a hardening item rather than an emergency, and it belongs in the pile with the other things that only matter once somebody already has a foothold. That pile is where the difference between a contained incident and an uncontained one usually lives.

inotifywait -m -e access,modify /dev/input

The question this leaves

The pattern in this research is not that four vendors were careless. It is that a facility built to be helpful was never modelled as a boundary, and then aged for two decades while everything around it grew stricter. Permissions on the files themselves are enforced. The metadata describing what happened to those files is not, because in 2000 nobody was thinking of a directory name as a secret, and by the time applications started naming directories after the websites you visit, the interface was too old and too widely used to revisit casually.

Microsoft's position is the most interesting because it is the most defensible and the most revealing. The check exists. The policy exists. The default stayed permissive, presumably because turning it on would break software that has depended on the old behaviour for a quarter of a century. That is a compatibility decision being described in the language of design intent.

Which is the question worth carrying away, and it is not really about file notifications at all: how many of the defaults in your estate are the way they are because somebody decided they were right, and how many because changing them would break something nobody wants to be responsible for?