FROST Browser Side-Channel: Using JavaScript OPFS Timing to Infer Other Apps

Researchers at Graz University of Technology have disclosed FROST, a browser-based side-channel technique that uses JavaScript and the Origin Private File System to infer other open websites and applications by measuring SSD timing behavior, with public reporting surfacing the work in late May 2026. The immediate temptation is to file this under “clever lab trick,” because it is clever, and because lab tricks often die before they reach the criminal economy. That would be too comfortable. FROST matters because it shows that the modern browser’s privacy boundary is no longer just cookies, tabs, permissions, or fingerprintable APIs; it is the whole client machine, including the storage device underneath it.

Diagram shows browser sandbox OPFS storage with timing-based side-channel leakage risk and SSD fingerprinting.The Browser Sandbox Now Has a Storage-Shaped Shadow​

For years, browser privacy debates have revolved around what a site is allowed to read. Can it see your cookies? Can it access your camera? Can it enumerate fonts, canvas behavior, GPU quirks, battery status, or local network devices? FROST is unsettling because it does not need to read the thing it wants to learn.
Instead, it watches the consequences of other activity. A malicious page can use the browser’s Origin Private File System, or OPFS, to create and access data on local storage from inside the browser sandbox. By timing those storage operations carefully, the page can detect contention: tiny slowdowns and patterns caused when other tabs, browsers, or applications are also talking to the same SSD.
That is the classic shape of a side channel. The attacker does not break into the room; they listen to the plumbing and infer who is taking a shower. In FROST’s case, the plumbing is SSD I/O, and the “listening” happens through JavaScript that a user may never notice beyond a page being open.
The research reportedly demonstrated website and application fingerprinting on macOS systems, with Apple devices receiving much of the attention because that is where the experiments were focused. But the broader lesson is not “Macs are uniquely doomed.” It is that browser features designed to make web apps feel native are steadily making the web page less like a document and more like a local process with excellent deniability.

OPFS Was Built for Serious Web Apps, Not Creepy Guesswork​

OPFS is not some obscure spyware interface smuggled into browsers under cover of darkness. It exists because modern web apps need persistent, high-performance local storage. If you want browser-based office suites, image editors, video tools, development environments, and offline-first apps, you need something better than the web storage primitives of the old cookie era.
That is precisely why FROST is hard to dismiss. The attack is not exploiting a comically unnecessary feature. It is exploiting the gap between a useful platform capability and a privacy model that still acts as though “same-origin” isolation is enough.
Same-origin rules are good at preventing a site from directly reading another site’s data. They are much less comforting when the attacking site can measure a shared resource with enough fidelity to infer what else is happening on the system. The SSD becomes a shared signal source, and OPFS becomes the instrument that lets a website tap out a rhythm and listen for interference.
This is the recurring bargain of the web platform. Every time browsers absorb another piece of native-app functionality, they inherit another category of native-app risk. The browser sandbox remains real, but it is no longer a clean room. It is a busy apartment building with thin walls.

The Attack Does Not Steal Files, Which Is Exactly Why It Is Easy to Underrate​

FROST does not appear to read your documents, exfiltrate your photos, or dump passwords from disk. That distinction matters, and scare headlines flattening it into “websites can read your SSD” are not helpful. The demonstrated attack is about inference, classification, and fingerprinting.
But privacy harms often begin as inference. If a site can distinguish whether you have a bank page open, a medical portal active, a competitor’s application running, or a particular messaging client in use, it does not need your files to learn something sensitive. The web advertising industry was built on exactly this kind of probabilistic knowledge: not certainty, but enough signal at enough scale to change how people are treated.
The research uses timing traces and machine-learning classification to associate observed SSD behavior with known activity patterns. That means an attacker would need training data and a target set of websites or applications worth identifying. It also means the attack is not magic; it is a guessing machine with constraints.
Still, “not magic” is not the same as “not dangerous.” A privacy attack that identifies a narrow set of high-value targets can be useful even if it fails elsewhere. An insurance site, an employer portal, a political campaign, a fraud operation, or a state-aligned surveillance actor does not need universal visibility if it can reliably answer a few uncomfortable yes-or-no questions.

The Mac Focus Should Not Let Windows Users Look Away​

The public examples have centered on Apple systems, and the original PC Perspective framing rightly emphasizes that the demonstrated privacy leak appears most relevant to Apple devices. That is the practical news hook. Windows users should not read that as absolution.
The underlying pattern is cross-platform in spirit: browsers expose high-performance APIs; local hardware creates measurable timing differences; machine learning improves classification; vendors argue about whether fingerprinting is a security bug or an anti-abuse problem. None of those ingredients belongs exclusively to macOS.
Windows machines, if anything, are a rich environment for this class of research. They run a vast mix of browsers, Electron apps, background updaters, cloud sync tools, antivirus scanners, game launchers, developer environments, and enterprise agents. That complexity can add noise, but it can also create distinctive patterns.
The reason this belongs on a Windows forum is not that FROST has suddenly become a turnkey Windows exploit. It is that the Windows ecosystem is already living in the future FROST describes: a world where the browser is an application runtime, storage is a performance dependency, and privacy defenses must account for shared hardware behavior rather than only web permissions.
Microsoft’s own browser strategy leans heavily into Chromium, progressive web apps, local integration, and cloud-connected experiences. That is not inherently bad. But the more the browser becomes a shell for everything, the less plausible it is to pretend that a web page is safely sealed away from the rest of the device.

Vendor Responses Reveal the Old Security-Privacy Divide​

The most revealing part of the FROST story may be the response pattern from browser vendors. According to public reporting, the findings were disclosed to Google, Apple, and Mozilla. Google reportedly did not classify fingerprinting as a security vulnerability, Apple considered the attack currently out of scope, and Mozilla acknowledged the issue without shipping a fix at the time of reporting.
That sounds evasive, but it reflects a real engineering dilemma. If every fingerprinting vector is treated as a conventional security vulnerability, browsers inherit an endless queue of hard-to-close leaks. Timing behavior, storage quotas, rendering differences, font availability, GPU behavior, and API edge cases can all contribute to identity or activity inference.
Yet the alternative is worse. If browser makers define “security” narrowly enough that cross-site behavioral surveillance falls outside it, users are left with a privacy model that protects secrets only when attackers ask for them politely. Modern tracking does not need to break the lock if it can identify the house from tire marks in the driveway.
The industry has been stuck here for years. Security teams like crisp bugs: memory corruption, sandbox escapes, credential leaks, permission bypasses. Privacy attacks are messier. They often combine allowed behaviors into a result nobody intended, and the fix may degrade performance, break apps, or require product decisions rather than patches.
FROST lands directly in that gray zone. It does not scream “remote code execution.” It whispers “unwanted observability.” For users, that distinction is academic if the result is a website learning what else they are doing.

The Gigabyte-Sized Footprint Is a Weakness, Not a Defense​

There are practical limitations. FROST needs to create and work with large files to get around caching and force meaningful storage interaction. Depending on browser policy and disk size, that can mean substantial OPFS storage consumption. In some cases, unusually large local site data may be visible to browser tools or extensions that inspect OPFS usage.
That is good news, but only in the narrow sense that the attack has friction. It is not the same as a user-facing permission prompt, a reliable browser warning, or a hard architectural mitigation. Plenty of abusive web behavior has survived despite being inefficient, noisy, or detectable by experts.
The “just look for a giant OPFS file” advice is useful for enthusiasts, but it is not a population-scale defense. Most users will not inspect per-origin storage. Many will not know that a web page can allocate meaningful disk space in the first place. Even among power users, storage bloat is easily mistaken for another browser cache, another offline app, or another modern web absurdity.
There is also a cat-and-mouse problem. Once a technique exists, later work often focuses on making it smaller, faster, quieter, or more specialized. The first demonstration does not have to be criminally convenient to be strategically important. It only has to show that a boundary leaks.

The Real Offender Is the Permissionless Web App Model​

The uncomfortable point is that FROST is less a one-off attack than an indictment of the permissionless web app model. Browsers routinely allow sites to run complex code, allocate storage, compile workloads, use graphics acceleration, and perform high-resolution measurements without asking users anything that resembles informed consent.
That model produced a web that feels powerful and frictionless. It also produced a web where visiting a page can mean letting a remote party borrow chunks of your CPU, GPU, memory, disk, and network stack for purposes you may never understand. Consent is mostly compressed into the act of loading the page.
Browser makers have tried to sand down the sharpest edges. Timers have been reduced or fuzzed in some contexts. Third-party cookies have been constrained. Privacy modes partition storage more aggressively than they used to. Anti-fingerprinting projects randomize or normalize some browser attributes.
But FROST shows how evasive the problem has become. When one signal gets blurred, attackers look for another. When direct identifiers become scarce, behavioral identifiers become more valuable. When browser APIs grow to support serious applications, they also grow to support serious observation.
The old privacy bargain was that websites could remember what you did on their site. The new bargain, if left unchecked, is that websites may infer what you are doing around their site. That is a very different proposition.

Security Tools May Miss What Privacy Tools Should Catch​

Traditional endpoint security is poorly suited to this kind of problem. There is no malware binary to quarantine. There may be no exploit chain, no persistence mechanism, no privilege escalation, and no forbidden file access. The suspicious activity is a web origin using a browser feature in an unusual way.
That does not mean defenders are powerless. Enterprise admins can control browser policies, storage settings, extension availability, script execution, and site isolation behavior. Privacy-focused users can reduce long-lived tab clutter, clear site data, use stricter browser profiles, or compartmentalize sensitive activity into separate browsers or containers.
But those mitigations are awkward because they fight the grain of everyday computing. People keep tabs open because browsers are workspaces. Enterprises rely on web apps because deployment is easier. Developers build rich browser tools because users expect native-like speed without installers.
The more realistic defense has to come from browser architecture. If OPFS can be abused as a timing probe, browsers need to ask whether storage operations can be rate-limited, partitioned, randomized, padded, permission-gated, or made less observable without breaking legitimate apps. None of those options is free, but privacy rarely is.
The hardest part will be deciding what kind of friction is acceptable. A browser that prompts every time a site wants local storage will become unusable. A browser that never constrains high-volume storage probing will become too trusting. Somewhere between those poles is a policy that treats large, high-frequency, timing-sensitive OPFS access as different from ordinary offline storage.

Apple’s Privacy Brand Meets a Hardware-Level Web Problem​

Apple’s appearance in the FROST story is awkward because the company has spent years marketing privacy as a product feature. Safari’s tracking prevention, App Tracking Transparency, on-device processing claims, and public positioning have all helped Apple draw a bright line between itself and the ad-tech economy.
FROST does not erase that work. It does, however, expose a limitation in privacy branding built around known tracker categories. Blocking third-party cookies and limiting cross-app identifiers does not automatically defend against a website that derives signal from SSD contention.
This is where Apple’s vertical integration cuts both ways. Because Apple controls hardware, operating systems, and Safari, it has unusual power to design mitigations across layers. It also has fewer excuses when a web-exposed hardware side channel becomes visible on its platform.
The same logic applies, in different form, to Google and Microsoft. Chrome and Edge sit atop enormous ecosystems that benefit from web app capability. The companies behind them are not neutral custodians of a tiny document viewer; they are platform operators. When the platform leaks privacy through “intended” APIs, the responsibility cannot be handed off entirely to users or researchers.
A privacy feature that only works against yesterday’s tracking method becomes a marketing artifact. The web’s next privacy fight is not about whether users can delete cookies. It is about whether browsers can stop remote code from turning local performance behavior into a telemetry feed.

The Tab Hoarder Is the Perfect Victim and the Perfect Excuse​

There is a comic version of this story in which the villain is the user with 73 tabs, three browsers, two chat apps, a spreadsheet, a password manager, and a half-finished shopping cart all open at once. Close your tabs, the joke goes, and the spies lose their signal. Like many tech jokes, it is funny because it dodges the actual issue.
Modern operating systems encourage persistent context. Windows desktops, macOS Spaces, browser tab groups, cloud-synced sessions, pinned web apps, and background services all exist because users are constantly switching between tasks. Keeping work open is not a moral failure; it is the normal state of computing.
That normal state gives side-channel attacks more surface area. A machine doing one thing is harder to classify. A machine doing ten recognizable things produces richer patterns. The very multitasking that makes computers useful also makes them observable.
Blaming tab hoarders also lets vendors avoid the platform question. If the defense is “behave less like a modern user,” the design has already failed. Privacy should not depend on pretending the web is still a sequence of static pages visited one at a time.
For Windows power users, the lesson is familiar. Complexity creates convenience, and convenience creates signals. The trick is not to abolish complexity, but to stop remote strangers from measuring it without permission.

FROST Is a Warning Shot for Browser Storage Governance​

The most constructive reading of FROST is that it gives browser vendors a chance to act before the technique becomes ordinary. The researchers have done what good security research is supposed to do: identify an unexpected leak, demonstrate feasibility, and force a policy conversation.
A sensible response would not be panic. It would begin with measurement. Browser teams should quantify how OPFS timing behaves across operating systems, SSD types, storage pressure conditions, and browser profiles. They should test how much mitigation comes from reducing timing precision, adding noise, changing cache behavior, or limiting suspicious access patterns.
They should also revisit storage transparency. If a site quietly consumes gigabytes of local disk, users deserve a clearer explanation than a buried settings page. The browser does not need to turn every allocation into a modal alert, but it should make abnormal storage behavior visible in the same spirit that browsers eventually made camera, microphone, and location access visible.
Enterprise controls matter too. Managed browsers should offer policies that restrict OPFS, cap per-origin storage, clear storage aggressively, or isolate sensitive web apps into profiles where cross-origin noise is reduced. Admins should not have to choose between “allow everything” and “break the web.”
The web platform can survive more restraint. What it cannot survive is a privacy model that treats every new side channel as someone else’s department.

The Frost Line Runs Through Every Open Tab​

The concrete lesson from FROST is not that everyone should panic-delete Safari or run their browsers from RAM disks. It is that browser storage has become a privacy surface, and the policies around it have not caught up with the power of the APIs.
  • FROST uses OPFS and JavaScript timing behavior to infer activity; it is not a direct file-reading attack.
  • The demonstrated work focused on macOS systems, but the architectural lesson applies to any platform where browsers expose high-performance local storage.
  • The attack has practical friction, including large storage use and the need for training data, which makes it more of a warning than a mass-exploitation story today.
  • Users can reduce exposure by separating sensitive browsing into dedicated profiles or browsers, clearing site data, and watching for unusually large per-site storage allocations.
  • Browser vendors need to treat privacy inference through shared hardware resources as a platform problem, not merely as an edge-case fingerprinting complaint.
The right response to FROST is neither shrugging nor sensationalism. It is to recognize that the browser has become powerful enough to observe the machine indirectly, and that privacy engineering has to move down the stack accordingly. If the next generation of web apps is going to behave more like native software, the next generation of browser defenses must stop pretending that origin boundaries alone can contain what those apps are able to sense.

References​

  1. Primary source: PC Perspective
    Published: 2026-05-29T19:40:40.274920
  2. Related coverage: techradar.com
  3. Related coverage: hothardware.com
  4. Related coverage: tomshardware.com
  5. Related coverage: ebisuda.net
  6. Related coverage: dday.it
  • Related coverage: hannesweissteiner.com
  • Related coverage: arstechnica.com
 

Back
Top