The browser feature that turns SSD timing into a tracking signal

A website no longer needs to read a file, break out of a sandbox, or install native code to learn something from a visitor’s SSD. New academic research describes FROST, a browser-based side-channel attack that measures solid-state drive contention through JavaScript and the Origin Private File System. The claim is not that a site can open your private files. The claim is narrower and more unsettling: by timing its own disk operations, a malicious page may infer what other websites or apps are doing on the same machine.

The new leak is not the file, but the rhythm of the drive

FROST matters because it shifts the privacy question from “Can a website access my files?” to “Can a website sense the pressure that other activity places on shared hardware?” That distinction is easy to miss. Browser security has long been built around logical boundaries: one origin should not read another origin’s data, scripts should not freely inspect another site’s DOM, and a sandboxed web page should not browse through a user’s documents. FROST does not try to tear down those boundaries directly. It listens for timing differences created when multiple tasks compete for the same SSD.

The paper, written by researchers from Graz University of Technology and collaborators, names the technique Fingerprinting Remotely using OPFS-based SSD Timing. The attack uses the browser’s Origin Private File System, or OPFS, as a way to create and repeatedly read from a large file controlled by the attacker’s own origin. The SSD remains shared by the operating system, the browser, other tabs, and native applications. When another site or app creates a recognizable storage workload, the attacker’s JavaScript sees small latency shifts in its own reads. Those shifts become a trace. A classifier then tries to match the trace to known activity.

That is the core trick. The malicious page does not need to violate the same-origin policy to learn something cross-origin. It uses a side effect of shared physical infrastructure. The same-origin policy restricts how a document or script from one origin interacts with resources from another origin, but side channels exploit measurements outside the protected object itself.

The research is also newsworthy because OPFS is not an obscure debugging hook. It is a standard web storage endpoint designed for serious web apps. MDN describes OPFS as private to the origin, not visible like the regular user file system, and optimized for performance and in-place file access. Google’s web.dev documentation says OPFS is supported across major browsers and notes that it has no permissions prompts because it is not meant to expose the user-visible file system.

A feature built for offline apps, large local data, and fast browser storage has become a measuring instrument. The privacy leak is produced by performance itself.

FROST turns OPFS into a timing probe

The FROST paper reports a drive-by browser attack. A victim visits an attacker-controlled page, perhaps directly, through a benign-looking page, through an ad, or from a spam link. With OPFS, the attack requires no file picker, no native app, and no additional user action after the page loads. The page creates a large file inside its own origin-private storage and performs random reads while timing them with JavaScript.

The random-read pattern is not incidental. The researchers write that they use random 4 KB reads across a large file to avoid prefetching effects and keep the operating system from serving all reads from cache. They also discuss creating a file larger than system memory in order to pressure the page cache and force disk reads over long measurements. That design matters because an attack that only measured memory cache behavior would be weaker and less clearly tied to SSD contention.

The name FROST points to the route into the browser: OPFS-based SSD timing. OPFS gives the page a fast, local storage surface. The SSD gives the page a shared physical resource. The browser gives the page JavaScript and timing APIs. Machine learning gives the attacker a way to convert noisy latency traces into guesses about websites or applications. None of these pieces is exotic on its own. The risk comes from their combination.

The paper’s abstract and evaluation report headline results that explain why security researchers are taking the work seriously. On a macOS system, the authors report an F1 score of 88.95% for top-50 closed-world website fingerprinting and 95.83% for application fingerprinting in a closed-world setting. In an open-world top-50 website-fingerprinting attack, they report a macro-averaged F1 score of 86.95%. They also report a covert-channel capacity of 661.63 bit/s on Linux and 891.77 bit/s on macOS when using OPFS.

Those numbers should not be read as proof that any random website can always identify every tab and app on every device. They come from controlled experiments. They depend on training data, device behavior, operating system behavior, browser behavior, and the activity being classified. The result is still serious because it shows that the browser’s storage stack can expose enough timing structure to support practical fingerprinting in research conditions.

The researchers say they responsibly disclosed the findings to Google, Mozilla, and Apple. According to the paper, the Chromium team stated that it did not consider fingerprinting attacks to be security vulnerabilities; Apple considered the attack out of scope at the time, while leaving room for a future mitigation; Mozilla acknowledged the findings but had not implemented mitigations at publication time.

A storage feature built for web apps became a sensor

OPFS exists because the web is no longer only a document viewer. Photo editors, design tools, IDEs, games, mapping tools, media apps, note-taking apps, scientific notebooks, and local-first databases all need fast local storage. IndexedDB is powerful but awkward for file-like workloads. Cookies are tiny and sent with requests. Local storage is synchronous and not suited for large binary work. OPFS gives each origin a private file system-like space and lets web applications manage files without asking the user to choose a folder.

From a product perspective, that is sensible. A browser-based video editor should not have to upload gigabytes to a server just to cache temporary media. A web app running SQLite through WebAssembly benefits from local byte-level access. A progressive web app may need durable offline data. OPFS answers those needs with a sandboxed design: the site sees only its own origin-private files, not the user’s desktop, downloads, or documents.

Security language often treats sandboxing as a binary property. The app is inside the sandbox, so it cannot reach outside. FROST shows the limit of that mental model. A sandbox can block direct access and still expose indirect measurements. The malicious page reads only its own OPFS file, but the time taken to read it depends partly on contention from other work hitting the same storage device.

That is not a strange bug in OPFS. It is a familiar property of shared computing. CPU caches, branch predictors, DRAM buses, GPUs, network paths, compression units, schedulers, and disks all leak timing under the right conditions. The hard part for an attacker is finding a measurement primitive with enough precision, low enough noise, and enough availability. FROST’s claim is that OPFS gives JavaScript such a primitive for SSD contention.

The browser feature’s good-faith purpose also complicates the defense. A permission prompt for every OPFS use would weaken many offline-first apps. Blocking large local files would break legitimate workloads. Adding noise to storage timing could hurt performance and may not remove the signal. Reducing timer precision helps against some timing attacks, but modern web apps also need accurate timing for profiling, media, games, and WebAssembly workloads. Browser vendors are not choosing between “privacy” and “no privacy.” They are deciding how much hardware-like capability a web page should get by default.

That is why the story is bigger than one paper. FROST is a warning about the native-app ambitions of the web platform. The closer the browser gets to local files, threads, WebAssembly, high-resolution timing, GPU access, and offline compute, the more it inherits the side-channel problems once associated mainly with local programs.

SSD contention is the hidden signal

A solid-state drive does not behave like a private tunnel for each process. It is a shared device with internal queues, flash translation logic, caches, controllers, NAND characteristics, firmware scheduling, operating system layers, and file system behavior. When one process creates I/O pressure, another process may observe changes in latency. The attacker does not need to know the victim’s data; the attacker measures delays in its own operations.

The FROST paper builds on prior SSD side-channel work. The earlier “Secret Spilling Drive” research studied timing channels inside commodity NVMe PCIe SSDs and showed that contention on SSDs could support covert channels and website fingerprinting. That prior line of work often relied on native code or lower-overhead system interfaces. FROST’s advance is to move the attack into the browser by using OPFS, which removes the need for a native application on the victim’s system.

The intuition is simple enough, but the engineering is not. A single read latency measurement is noisy. Operating systems cache aggressively. Browsers schedule work. Other processes run. The SSD itself may behave differently depending on model, temperature, firmware, wear state, request queue depth, and power management. FROST handles this by building traces over time rather than treating any single delay as decisive.

A website visit can leave an I/O pattern. Loading a page may pull cached resources, update browser state, write storage data, touch profile databases, and trigger media or script work. A native application launch may read libraries, configuration files, caches, and assets. These patterns are not the content of the user’s activity; they are the storage rhythm around it. If the rhythm is consistent enough across examples, a trained model may recognize it.

This is what makes side-channel attacks feel uncanny. Traditional access control asks whether code is permitted to read a file, query a site, or call an API. Side channels ask whether code can measure the world around the protected thing. The attacker watches latency, not secrets. But latency may still reveal sensitive facts: a medical portal was loaded, a password manager window opened, a crypto wallet app launched, a workplace tool ran, or a competitor’s dashboard was visited.

FROST does not prove all of those examples in the wild. The paper specifically demonstrates website and application fingerprinting under its tested setup. The lesson is broader: storage latency can carry behavioral metadata, and metadata often matters even when content stays encrypted or sandboxed.

The attack model starts with one malicious page

FROST’s threat model is not a remote code execution exploit. The attacker does not need a browser vulnerability in the usual sense. The victim must visit a page containing attacker-controlled JavaScript. Once loaded, the page performs its measurements in the background while the victim uses the machine. The researchers describe possible delivery through an attacker-controlled website, advertising, or spam.

That matters for risk assessment. A drive-by side-channel page is easier to distribute than a native malware payload, but it is still constrained. The attack depends on the page staying open long enough, on the browser allowing the needed storage and timing behavior, on the device having a susceptible storage setup, and on the attacker having training data relevant to the victim environment. It is not a magic window into someone’s SSD.

The no-interaction part is the unsettling part. OPFS differs from user-visible file access. A website asking to open a local document through a picker must involve the user. A website using OPFS to create its own private storage does not. The web.dev OPFS article states that OPFS is not visible to the user and has no permissions prompts or Safe Browsing checks because it is private to the origin rather than the user-visible file system.

That design makes sense for benign apps. It also gives malicious code a quiet setup phase. The attacker can allocate storage, create a large file, and begin sampling without producing the kind of visible prompt that would alert a user. Site data clearing may remove the OPFS file later, but clearing data after the fact does not stop measurements already collected.

The attack also fits badly with common user expectations. People understand, at least roughly, that a site might track clicks, set cookies, read browser-visible attributes, or run analytics scripts. Few expect a web page to measure an SSD’s latency as a proxy for other activity. The surprise comes from the gap between the browser’s visible permission model and the physical measurements available underneath it.

The same point applies to website operators. A publisher embedding third-party scripts may not understand whether those scripts use OPFS, high-resolution timing, WebAssembly, or storage measurement. Content Security Policy can restrict which scripts run, but it cannot tell whether a trusted advertising or analytics script is behaving in a privacy-preserving way once allowed. CSP reduces script injection and source risk; it is not a behavioral privacy auditor.

Reported accuracy deserves careful reading

The most quoted FROST numbers are striking: roughly 89% F1 for closed-world top-50 website fingerprinting, roughly 96% F1 for application fingerprinting, and roughly 87% macro-averaged F1 for open-world top-50 website fingerprinting. Tom’s Hardware summarized the same result as identifying visited websites with roughly 89% accuracy and running applications with roughly 96% accuracy on a test Mac, while Ars Technica reported the technique as a new way for sites to monitor other sites a visitor is viewing and what apps are open.

Those summaries are fair at headline level, but F1 score is not a casual synonym for universal real-world accuracy. An F1 score combines precision and recall. A closed-world experiment assumes the target belongs to a known set, such as one of 50 websites. An open-world experiment adds a more realistic problem: the user may visit something outside the monitored set, and the model must avoid false positives. A high closed-world score often drops when the target set gets larger, the environment changes, or background noise grows.

The FROST paper explicitly distinguishes these settings. It reports a closed-world website fingerprinting F1 score of 88.95%, an application fingerprinting F1 score of 95.83%, and an open-world top-50 website fingerprinting macro-averaged F1 score of 86.95%. A screenshot of the paper’s Figure 6 also shows a macro-averaged F1 score of 86.95% with open-world accuracy of 96.72% for the OPFS website-fingerprinting experiment.

The difference between “visited websites” and “any website” is crucial. A model trained on traces for 50 specific websites is not automatically a model for every website. A model trained on one hardware and software setup may not transfer cleanly to another. A browser update, SSD firmware difference, operating system setting, cache state, or user workload may change the traces. Attackers can train per target class, but collecting useful traces at scale costs work.

The right reading is neither panic nor dismissal. FROST shows that browser-accessible SSD timing contains enough information for strong classification in controlled tests. It does not show a turnkey advertising tracker that identifies every page and app on every consumer device today. Serious privacy engineering lives in that middle ground.

Browser timers remain a recurring weak point

FROST needs timing. Browser timing has been a security problem for decades because side-channel attacks often turn small delays into information. Browsers responded to Spectre and other timing attacks by reducing timer precision, gating some powerful features behind cross-origin isolation, and relying more heavily on process isolation. Chrome’s 2021 timer change restricted explicit timers to 100 microseconds across platforms by default, while allowing 5 microseconds in cross-origin isolated contexts. MDN describes similar coarsening, with high precision timing reduced based on isolation status.

The FROST paper says its measurements use performance.now() and configure COOP/COEP headers to enable high-resolution timers. Cross-origin isolation is not a vulnerability by itself. It is a browser mechanism that gives pages stronger isolation from cross-origin resources in exchange for access to features such as SharedArrayBuffer and better timer precision. Google’s web.dev guide says cross-origin isolation is required for SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), and high-resolution timers with better precision.

The tension is visible. Cross-origin isolation was partly designed as a safer way to restore powerful capabilities after Spectre-era restrictions. But FROST’s threat is not simply one page reading another page’s memory in the same process. It is a page measuring storage contention at the device level. Process isolation and origin boundaries do not remove the shared SSD. A page can be well-isolated from another page’s memory and still observe timing changes caused by shared hardware.

Timer reduction is also an imperfect tool. If the signal is large enough or repeated enough, coarse timers may still reveal patterns. Attackers can build their own timers in some situations, combine repeated measurements, or use APIs with implicit timing. If browsers make timers too coarse, performance tooling and legitimate web apps suffer. The result is an arms race in small numbers: microseconds, milliseconds, sampling rates, jitter, noise, and compatibility.

The deeper issue is not only timer precision. It is the number of web APIs that turn a page into a local measurement agent. Storage APIs, performance APIs, WebAssembly, workers, graphics APIs, audio APIs, and network timing all give scripts ways to observe behavior. Each feature may be defensible on its own. Their composition is where side channels grow.

The same-origin policy cannot contain physical side effects

The same-origin policy is one of the web’s core safety mechanisms. It keeps a script loaded from one origin from freely reading resources belonging to another origin. It stops a malicious page from directly inspecting a logged-in banking tab or pulling private data from another site’s DOM. Without it, ordinary browsing would be unsafe.

FROST does not defeat the same-origin policy in the direct sense. The attacker-controlled page reads and writes its own OPFS data. It does not gain file-system access to another origin’s OPFS. It does not open a victim’s documents. It does not read another page’s HTML. The same-origin policy does its intended job at the object level.

The leak lives below the object level. The attacker and victim share hardware. The attacker measures its own work. Victim activity changes the timing environment. The distinction is familiar in cache attacks: a spy process does not read the victim’s memory; it measures which cache sets became hot or cold. FROST applies a related idea to SSD contention from a browser.

This is the uncomfortable lesson for browser security design. Logical isolation does not automatically produce physical noninterference. A browser may isolate origins, processes, site instances, cookies, storage partitions, and permissions while still exposing shared resource contention. The web platform increasingly offers local capabilities once reserved for native code, so it must reckon with native side-channel classes.

Site isolation helps against some attacks by placing sites into separate renderer processes and relying on the operating system to protect process memory. Google’s 2018 Site Isolation post framed it as a major Chrome architecture change to limit each renderer process to documents from a single site. That defense was shaped by Spectre-like risks, where process boundaries can reduce what secret data is available in an attacker’s address space.

FROST points at a different layer. Separate renderer processes still write to the same storage device. The browser can wall off memory and DOM access, but it cannot make the SSD private to each origin without heavier storage scheduling, artificial delays, quotas, permission gates, or device-level partitioning. Some of those defenses would be expensive. Some would be incomplete. Some would hurt exactly the offline app use cases OPFS was built to support.

OPFS storage quotas do not solve this problem

Browser storage quotas limit how much data an origin may store and when data may be evicted. They prevent a website from quietly consuming unlimited disk space. MDN’s storage quota documentation describes browser limits and eviction criteria; web.dev distinguishes best-effort storage, which may be cleared under pressure, from persistent storage, which requires more deliberate removal.

Quotas matter for FROST because the attack needs a large enough OPFS file to create useful disk reads and avoid being fully cached. The FROST paper discusses large files and page-cache behavior. OPFS is subject to browser storage rules, but a quota is not a privacy defense against timing measurement unless it prevents the measurement primitive from working. The paper’s authors found enough room and performance to make the attack viable in their setup.

A user might assume that “private to the origin” means private from privacy risk. It means private from other origins reading that storage. It does not mean the storage is invisible as an I/O workload. The drive still receives commands. The operating system still schedules work. The browser still needs to persist data somewhere. The SSD still responds with variable latency.

Clearing site data may delete OPFS data. That is useful hygiene. It does not stop a page while it is open. Blocking third-party cookies does not block first-party OPFS use on a malicious site the user visits directly. Private browsing may reduce persistence, but the attack’s measurement phase may not require persistence across sessions. Quota eviction may remove old files, but FROST’s traces are collected during active measurement.

Storage governance was designed mainly around capacity, persistence, and direct access. FROST turns storage into a sensing problem. Capacity rules alone are not enough when the attacker values timing, not data retention.

This is where browser UI lags browser capability. Users see cookie banners, file picker prompts, camera prompts, microphone prompts, location prompts, and notifications prompts. They do not see a storage-timing prompt. That gap may be acceptable for most benign storage. It becomes harder to defend when a no-prompt storage API supplies enough precision to infer cross-application behavior.

The first compact view of the FROST claim

FROST at a glance

The table compresses the research into its moving parts, but it should not flatten the conclusion. The strongest claim is not universal surveillance; it is that OPFS gives ordinary JavaScript enough low-level storage access to support a remote side channel under tested conditions.

Prior browser side channels made this predictable

FROST feels novel because the signal comes from SSD activity, but browser side channels are not new. In 2015, “The Spy in the Sandbox” presented a microarchitectural side-channel attack running entirely in the browser, showing that untrusted web content could use cache behavior to infer activity without installing software. Later work studied browser-based cache attacks with fewer JavaScript dependencies, including techniques built from CSS and HTML.

The lineage matters. Browser vendors have repeatedly narrowed one measurement source only to see researchers discover another. Cache timing, event loops, DNS cache timing, GPU behavior, memory pressure, storage quotas, speculative execution, and network timing all offer ways to infer state indirectly. FROST adds a storage-device path that benefits from a modern browser feature designed for real applications.

This is not a sign that browsers are careless. It is a sign that browsers are ambitious. Every step toward native-like power exposes local machine characteristics. JavaScript no longer only changes text and images on a page. It runs WebAssembly, processes media, stores large local datasets, uses workers, draws with GPU-backed APIs, and may operate as a serious desktop replacement. The web platform’s success creates the conditions for side-channel risk.

The research community has also become better at turning weak signals into classifiers. Early timing attacks often required crisp thresholds. Modern attacks can use convolutional neural networks, trace preprocessing, repeated sampling, and open-world evaluation. FROST’s paper trains a CNN on latency traces to classify websites and applications. That choice reflects a larger shift: when the signal is noisy but structured, machine learning can make it useful.

This is why “the timing differences are tiny” is not a safe rebuttal. Tiny timing differences become informative when sampled repeatedly, aligned, cleaned, and compared to known patterns. A single footprint in snow says little; a path of footprints can identify direction, gait, and destination. SSD latency traces work in that spirit.

The same history also argues against panic. Many academic side channels are difficult to exploit at scale. Browser mitigations, OS changes, hardware differences, and user behavior can reduce practical reach. The value of FROST is that it reveals a class of leakage early, before it hardens into a production tracking technique.

The attack is more about behavioral metadata than data theft

A reader may ask whether FROST steals files. Based on the paper, no. The attack is not presented as a way to read private documents or extract the contents of another origin’s storage. It is a way to infer activity through SSD contention. The information leaked is behavioral metadata: which website from a trained set may have loaded, which application from a trained set may have opened, or whether a cooperating sender transmitted bits through a covert channel.

That does not make the issue harmless. Metadata often carries private meaning. A website category may reveal health concerns, political interests, legal needs, financial distress, job searches, union activity, adult content, religious practice, or workplace tools. An app launch may reveal that a user opened a password manager, a messaging client, a VPN, a tax program, a trading app, a design tool, or an enterprise app.

Privacy debates often focus on content because content feels obvious. The message text, the photo, the bank statement, the diagnosis, the password. Side channels usually live one layer away. They reveal timing, presence, sequence, frequency, or category. That layer can be enough to harm a person, especially when combined with other identifiers.

A malicious advertiser does not need to know the content of a medical page if it can infer that a user likely loaded one of several medical sites. A phishing operator does not need to read a work app if it can infer that the app is installed or active. A hostile site does not need to read a crypto wallet if it can detect wallet software opening. These examples go beyond what FROST proves directly, but they show why activity fingerprinting has real stakes.

The privacy boundary at issue is the boundary around attention and behavior. Users expect one website not to know what else they are doing on the machine. FROST shows one path by which that expectation can fail without direct data access.

This is also why browser vendors and regulators sometimes treat fingerprinting differently from classic security bugs. A memory corruption flaw that leaks passwords is clearly a security vulnerability. A measurement technique that improves tracking or activity inference sits between privacy, abuse, platform design, and security. The harm is real, but it does not always fit vulnerability triage systems built around confidentiality, integrity, and availability of protected data objects.

The browser vendor response exposes a policy gap

The FROST paper’s disclosure section is unusually revealing. The authors say Chromium security did not consider fingerprinting attacks to be security vulnerabilities. Apple considered the attack out of scope at the time but may implement a mitigation in the future. Mozilla acknowledged the findings but had not implemented mitigations yet.

Those responses should be read as platform policy signals, not casual dismissals. Browser vendors receive many reports involving fingerprinting surface. If every additional measurable bit became a security bug, vulnerability programs would be flooded with issues that may require product-level privacy decisions rather than patches. A vendor may believe that a behavior is bad for privacy while still treating it outside the security bug bounty process.

That distinction creates a gap for users. If a flaw is “security,” it may receive urgent triage, CVE handling, coordinated release notes, and clear mitigation. If it is “fingerprinting,” it may move through standards debate, privacy working groups, product planning, and compatibility analysis. The second path can be slower and less visible.

The W3C’s fingerprinting guidance recognizes the problem at the standards level. It advises specification authors to consider fingerprinting surface, minimize unnecessary exposure, and document privacy impact. The W3C TAG’s unsanctioned tracking finding warned that tracking outside user control and transparency is harmful to the web and that new specifications should take reasonable measures to avoid adding unnecessary fingerprinting surface.

FROST gives that guidance a concrete test. OPFS has strong uses. It is not unnecessary. The question is whether its performance characteristics and permission model expose more measurement power than the web should grant silently. If a feature is powerful and useful, the answer cannot be “remove it” by default. It may need scoping, permission changes, noise, rate limits, partitioning, background throttling, storage-size thresholds, or better detection of abusive measurement loops.

The platform gap is that browser privacy risk often has no single owner. Standards bodies define APIs. Browser teams implement them. Security teams triage vulnerabilities. Privacy teams assess fingerprinting. Web developers adopt features. Advertising and analytics ecosystems search for signals. Users inherit the result.

Cross-origin isolation helps and hurts the story

Cross-origin isolation is relevant to FROST because better timer precision can be gated behind it. To become cross-origin isolated, a site must use headers such as Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy. These headers limit relationships with cross-origin resources and are meant to make powerful features safer. web.dev’s guide says sites should evaluate the impact on cross-origin resources such as ads before enabling it.

This creates a paradox. A site that opts into stronger isolation may gain access to better timers, which may improve certain side-channel measurements. The isolation reduces one class of cross-origin risk while the timer precision may support another class of local side-channel risk. Security engineering often looks like this: a mitigation is tuned for one threat model, then another threat model stresses its side effects.

The answer is not to abandon cross-origin isolation. It has real value for Spectre-era web architecture and powerful features. Google’s Site Isolation work and later isolation mechanisms responded to the fact that speculative execution attacks could expose data within the same process. Restricting cross-origin relationships and separating sites into safer process boundaries are rational defenses.

FROST says the browser cannot treat process isolation as a complete answer to side channels. The SSD is outside the renderer process. A high-resolution timer inside a well-isolated context may still measure shared device contention. That does not make cross-origin isolation wrong; it means the platform needs a layered view of physical resources.

One possible browser response would be to reduce timer precision even in isolated contexts when pages use OPFS in suspicious ways. Another would be to add jitter or scheduling noise to OPFS operations. Another would be to limit large OPFS files without user activation. Another would be to throttle background pages performing high-frequency random reads. Each option risks compatibility problems and may be bypassed.

FROST puts pressure on the bargain behind powerful web features: if a page gets closer to native performance, it also gets closer to native side-channel risk.

Advertising would value this signal, but abuse is not limited to ads

The immediate public reaction to browser fingerprinting often turns to advertising. That is reasonable. Online advertising has a long history of turning small browser differences into persistent identity or targeting signals. As third-party cookies face restrictions, the incentive to find alternative tracking signals grows. Browser fingerprinting does not depend on cookies alone, which is one reason Firefox describes it as harder to detect and reset.

FROST’s signal is not a classic stable browser fingerprint like screen size, installed fonts, canvas output, or WebGL characteristics. It is more like a local activity sensor. That may make it useful for different abuse cases: detecting whether a user is visiting a competitor, inferring app usage, enriching a profile with behavioral categories, or linking a browsing session to machine state. It could also be combined with conventional fingerprinting, cookies, IP address, login state, or first-party data.

The regulatory concern is not hypothetical. The European Data Protection Board’s 2024 guidance on the technical scope of Article 5(3) of the ePrivacy Directive says storing information or gaining access to information already stored in terminal equipment generally requires consent unless a narrow exemption applies. The UK ICO’s guidance says PECR applies to technologies that store information or access information stored on a user’s terminal equipment, and that UK GDPR may also apply where personal data is involved.

A pure timing side channel raises hard legal questions because the attacker may not “read” a stored file in the ordinary sense. It may store its own OPFS file and measure the latency of accessing it. Still, the purpose may be tracking or inferring information from the user’s device. Regulators have generally treated device fingerprinting and similar storage-access technologies as privacy-relevant even when cookies are not used. The legal analysis would depend on implementation, jurisdiction, purpose, identifiability, transparency, consent, and whether personal data is processed.

Abuse is not limited to advertising. A phishing site could look for signs that a target uses a particular enterprise app. A hostile site could infer whether a journalist opened a secure communications tool. A scam page could adapt based on whether banking or crypto apps appear active. A surveillance actor could pair FROST-like signals with network metadata. The same technical primitive may serve fraud detection, research, analytics, malware staging, or tracking. The moral status comes from deployment, not from timing alone.

Enterprise risk is different from consumer risk

For ordinary users, FROST’s near-term risk is likely tied to malicious websites, sketchy ad placements, and privacy-invasive scripts. For enterprises, the risk picture changes. Corporate endpoints often have predictable hardware, standardized browser builds, common application sets, and repeated internal workflows. Predictability can make fingerprinting easier. A model trained on one fleet image may transfer better across similar machines than across the consumer device market.

An attacker targeting a company may not need broad classification. They may care about a short list of internal tools: a VPN client, a password manager, a secure file-transfer app, a trading terminal, an incident-response console, a CAD tool, a privileged admin portal, or a customer database interface. If those tools produce consistent storage traces, a browser-based probe might help with reconnaissance.

Enterprises also embed third-party scripts in internal and external web apps. Analytics, chat widgets, support tools, tag managers, customer success platforms, A/B testing frameworks, monitoring scripts, and advertising tags may run inside pages with access to web APIs. A compromised third-party script could be a delivery vehicle. CSP and subresource controls reduce some risk, but they cannot fully solve the problem when the script source is trusted but the behavior becomes abusive.

Endpoint detection tools may not flag a web page performing random reads inside OPFS. From the operating system’s point of view, the browser is reading its own profile or storage data. From the browser’s point of view, the page is using a permitted API. From the network’s point of view, the page may send only compact trace summaries. Detection would require new heuristics: large OPFS allocation, repeated random-access loops, high-frequency timing collection, background execution patterns, unusual storage pressure, or suspicious model inference.

The enterprise question is not only “Which browser patch fixes this?” It is “Which web code do we allow to run on machines that handle sensitive workflows?” That pushes the issue into script governance, browser policy, extension policy, isolation of high-risk work, remote browser isolation, and endpoint telemetry.

In tightly controlled settings, administrators could block or restrict certain APIs through enterprise policies if browsers expose controls. They could separate sensitive apps into dedicated browser profiles or hardened browsers. They could restrict third-party scripts on internal apps. They could train users not to mix untrusted browsing with sensitive work. None of those steps is perfect. They show why side-channel risk is operational, not only academic.

User-level defenses are blunt but not useless

A user cannot easily inspect whether a page is using OPFS as a timing probe. Browser developer tools may show site storage after the fact, but ordinary browsing does not expose a clean warning. That limits user-level defense. Still, several habits reduce exposure.

Closing untrusted tabs matters. FROST needs the malicious page running while other activity occurs. A page that is no longer open cannot keep sampling. Browser background throttling may reduce some activity, but relying on throttling alone is unsafe because browsers differ and pages may use workers or foreground tricks. Keeping sensitive tasks in a separate browser profile or a separate browser can reduce some shared browser-state signals, though it does not necessarily remove SSD-level sharing.

Private windows may reduce persistence of site data, but they do not guarantee protection from a live timing attack. Clearing site data removes OPFS storage for an origin, but the value of FROST lies in measurement while the page is active. Blocking unknown scripts with privacy extensions may reduce exposure, especially on ad-heavy pages, but script blockers can break sites and may not block first-party malicious pages.

Privacy-focused browsers may offer stronger fingerprinting resistance. Tor Browser includes defenses such as letterboxing, user-agent spoofing, and first-party isolation. Brave documents fingerprinting protections based on blocking, modifying, or randomizing APIs. Firefox includes protections against known and suspected fingerprinters and has advanced resist-fingerprinting settings that can reduce identifying signals at some compatibility cost.

Whether those defenses stop FROST specifically depends on details: timer precision, OPFS availability, storage behavior, background throttling, and how the attack is implemented. A privacy browser that blocks or degrades one signal may still expose another. A hardened setup that severely coarsens timers may make FROST harder but may also break performance-heavy web apps.

The practical user advice is modest: avoid leaving untrusted pages open during sensitive work, use hardened browsers for high-risk browsing, clear site data for suspicious origins, and separate sensitive workflows from general web surfing where possible. That advice is not satisfying because the better fix belongs in browsers and standards, not in user vigilance.

Browser makers face a performance privacy tradeoff

The most direct defense against FROST would be to make OPFS less useful as a timing source. That could mean permission prompts for large OPFS allocations, lower timer precision when storage operations are measured, randomized delays, reduced read throughput from untrusted contexts, background throttling, caps on high-frequency random reads, or storage scheduling that reduces cross-origin and cross-application contention observability.

Every option has costs. Permission prompts may train users to click through or may confuse them because OPFS does not expose user-visible files. Random delays may punish legitimate apps that use OPFS for local databases, media editing, games, CAD, data analysis, or offline-first work. Large-file limits may break use cases involving local models, maps, videos, archives, and scientific data. Timer restrictions may hurt profiling and high-performance web apps. Behavior-based detection may miss clever attacks and flag legitimate benchmarks.

The browser’s default posture is therefore hard. OPFS is not a niche experiment. The File System Standard defines infrastructure for file system APIs and includes a way for websites to access a file system directory without first prompting the user, precisely to support saving data before a user chooses an external location.

One path is to treat OPFS as safe for direct confidentiality but sensitive for fingerprinting. That would put it in the same family as canvas, audio, WebGL, fonts, and performance APIs: useful by design, measurable by abuse. Browser vendors could expose OPFS under normal conditions but reduce its precision as a sensor. For example, a page that performs many random reads solely for timing might be throttled differently from a page doing ordinary sequential storage work. That is easier to describe than to implement.

Another path is permission design. Instead of prompting for every OPFS use, browsers could prompt for unusually large storage allocations, long-running high-rate access, or background storage measurement. Yet a prompt reading “Allow this site to use local private storage?” may not convey side-channel risk. A user may assume the risk is disk space, not activity inference.

FROST’s hardest product question is whether users deserve a visible choice when a website gets enough local storage power to become a hardware sensor.

Standards groups need to treat performance as fingerprinting surface

The W3C fingerprinting guidance is aimed at specification authors, and FROST fits its logic closely. A web feature may expose direct identifying attributes, such as installed fonts or hardware details. It may also expose indirect differences through performance. The latter is harder to document because performance is usually treated as a quality goal. OPFS was designed to be fast. That speed is part of the problem.

A privacy review of storage APIs cannot stop at “the origin cannot read another origin’s files.” It must ask whether an origin can infer another origin’s activity. It must ask whether the API allows repeated high-resolution measurements of shared resources. It must consider whether the feature works in workers, whether it runs in the background, whether it needs user activation, how quotas affect measurement, and whether timing is exposed directly or indirectly.

The W3C Privacy Principles state that privacy is part of the web and that web users benefit from stronger relationships between technology and policy. That broad principle becomes concrete here. A user’s browsing and app activity are part of their private sphere even when no content is copied. Standards work must address behavioral inference, not only storage access.

The OPFS case also shows why “private to the origin” is not enough as a privacy phrase. To engineers, it means one origin’s files are isolated from another. To users, it may sound like the browser is protecting them from hidden observation. Documentation should be more precise. A feature can be origin-private, quota-limited, and still timing-sensitive.

Specification privacy reviews should treat high-performance local APIs as potential side-channel endpoints by default. That does not mean rejecting them. It means documenting the risk, testing abuse cases, giving implementers mitigation hooks, and avoiding designs that make measurement easier than necessary.

The web platform already went through a similar adjustment with high-resolution timers after Spectre. Timer precision became a policy surface. FROST suggests storage performance needs the same kind of attention.

The legal issue is consent, transparency, and purpose

If a website used FROST-like techniques for tracking, it would likely face scrutiny under privacy laws in Europe and the UK, though exact obligations would depend on implementation. The EDPB’s ePrivacy guidance focuses on storing information or gaining access to information stored in terminal equipment. The ICO’s storage and access guidance says PECR applies to technologies that store or access information on a user’s device, and UK GDPR applies where personal data is involved.

A malicious FROST page stores its own OPFS file and reads it. The inferred signal comes from timing differences produced by the user’s device state and activity. Lawyers would likely ask whether the technique gains access to information stored or generated in terminal equipment, whether the inferred data is personal data, whether the user was informed, whether consent was obtained, and whether the purpose is strictly necessary for a service the user requested.

Fingerprinting has long challenged notice-and-consent models because users cannot easily see it, clear it, or understand its components. Cookie banners at least refer to a recognizable storage object, however imperfectly. A storage-timing side channel is harder to explain. A consent banner saying “we measure SSD latency to infer other activity” would be honest but alarming. A vague “device signals” disclosure would be less transparent and likely open to challenge.

The ICO has been vocal about fingerprinting in advertising contexts, warning that it can reduce user choice and control. Although that public debate has focused on advertising identifiers and device fingerprints rather than FROST specifically, the underlying concern is the same: tracking that users cannot easily detect or reset undermines meaningful control.

The legal risk for legitimate sites is broader than direct use. If a site embeds third-party code that performs invasive measurement, the site may still face accountability questions. Data protection law often looks at controllers, processors, purposes, and joint responsibility. A publisher cannot assume that a script’s technical complexity makes it someone else’s problem.

FROST-like tracking would be hard to reconcile with privacy-by-design promises unless it were disclosed clearly, justified narrowly, and controlled tightly. For most advertising or analytics uses, that is a steep hill.

The research limits are real

FROST is not a universal browser spying device. The paper’s strongest results are bounded by the experiment. The authors collected traces in specific environments, trained models, and evaluated known classes of activity. Real users run many tabs, background services, sync clients, antivirus tools, cloud backup agents, messengers, and browser extensions. Their SSDs differ. Their caches differ. Their browsers update. Their devices sleep, throttle, heat up, and run low on space.

Noise can cut both ways. Extra background activity may drown out a target signal. It may also create new signals for a model trained on real-world traces. The practical question is not whether FROST works perfectly everywhere; it is whether an attacker can find valuable environments where it works well enough. Targeted attacks often need only a small number of reliable inferences.

Hardware differences matter. SSD controllers vary. Some use host memory buffers. Some have DRAM. Some handle queues differently. Laptops may alter power behavior on battery. Operating systems differ in caching and I/O scheduling. Browsers differ in OPFS implementation, timer behavior, worker behavior, and background-page throttling. A paper’s test machine cannot represent the whole web.

The attack also requires time. The malicious page must gather enough samples while the victim performs target activity. If a user closes tabs aggressively, uses separate profiles, or performs sensitive work in a hardened browser, measurement gets harder. If a site is loaded in an ad iframe with limited execution or storage access, the attack conditions may differ. If browser vendors change OPFS timing behavior, the attack may need adaptation.

The correct lesson is conditional risk, not deterministic doom. FROST is a proof that an unexpected browser feature can cross the threshold from harmless storage to practical side-channel measurement. Whether criminals adopt it depends on ease, payoff, stealth, defenses, and availability of simpler tracking methods.

That last point matters. Attackers are lazy when they can be. Cookies, login IDs, IP addresses, device fingerprints, browser APIs, URL parameters, and server-side data often provide cheaper tracking. FROST becomes attractive when the attacker wants local activity inference that other techniques cannot provide.

The research impact is larger than the immediate exploit

Academic side-channel work often looks ahead of real-world abuse. That is a feature, not a defect. The point is to find design weaknesses before they become commercial surveillance infrastructure or advanced attack tooling. FROST’s value is that it names a new browser-exposed storage side channel while the platform still has time to react.

The paper also connects previously separate discussions. Web developers think about OPFS as storage. Browser security teams think about site isolation, permissions, and timers. Hardware researchers think about SSD contention. Privacy teams think about fingerprinting. FROST sits at the junction. It says a storage API, a hardware device, and a timing API together create a privacy leak.

That cross-layer quality is where modern security problems increasingly live. No single layer is “wrong.” The SSD is doing its job. The operating system is caching and scheduling. The browser is exposing a standard API. JavaScript is timing operations. The classifier is recognizing traces. The leak emerges from composition.

FROST is a composition failure. It is not a simple memory bug. It is not a missing permission on a file picker. It is not merely a bad timer. It is the web platform giving a remote page enough local capability to sense a shared device. That type of failure is hard to patch after deployment because each component has legitimate uses.

This also means the next FROST may not involve SSDs. It may involve neural processing units, GPU memory pressure, local AI model caches, hardware video decoders, browser-managed databases, compression engines, WebUSB-like device paths, or scheduling artifacts in multi-tab environments. As browsers expose more device-adjacent capability, privacy reviews must model interaction with the whole machine.

Developers should treat third-party scripts as local code

Most website owners do not write side-channel code. They may still run it. Tag managers, analytics libraries, ad scripts, personalization tools, session replay, fraud scripts, consent platforms, and A/B testing tools often execute with broad access in the page. If any one of those scripts uses OPFS timing, the user experiences it as behavior of the site.

Content Security Policy is a starting point. It lets a site define which script sources are allowed and can reduce the risk of injected or unexpected code. MDN describes CSP as a browser-enforced set of restrictions on what site code is allowed to do, and the script-src directive specifically controls valid JavaScript sources.

CSP does not solve trusted-script abuse. A site that whitelists a third-party analytics domain permits that code to run. Subresource Integrity can pin static scripts, but many third-party tags are dynamic. Sandboxed iframes can constrain some behavior, but advertising and analytics integrations often demand broad permissions. Permissions Policy may restrict some APIs, but OPFS and related storage controls are not always exposed in a way that site owners can manage cleanly across browsers.

The practical developer response is governance. Audit third-party scripts. Remove scripts that do not have a clear business purpose. Avoid broad tag-manager sprawl. Use CSP reporting. Separate untrusted scripts into sandboxed frames where possible. Prefer server-side measurement when client-side code is not needed. Monitor unexpected storage use. Ask vendors whether they use OPFS, high-resolution timing, fingerprinting, or local device signals.

A script running in the browser is not “just analytics.” It is code executing on the user’s machine with access to powerful web APIs. FROST makes that sentence less theoretical.

For high-trust sites such as banks, health providers, government services, legal platforms, newsrooms, and enterprise SaaS apps, script minimization is not only performance work. It is privacy and security work. The fewer parties allowed to run code in a sensitive page, the fewer parties can experiment with side channels.

Browser extensions could both defend and attack

Browser extensions add another layer. A privacy extension could detect high-volume OPFS use, reduce script access, block known trackers, clear site data, or warn about suspicious storage patterns. Some extensions already block fingerprinting scripts or reduce known tracking surfaces. In theory, an extension could instrument OPFS-related calls and flag repeated random reads.

Extensions also create risk. A malicious or compromised extension may have broader visibility than a web page, depending on permissions. It may run across sites, observe navigation, inject scripts, or access page content. If a browser-based side channel becomes useful, extensions could adopt it too, possibly with fewer restrictions than ordinary pages. That risk is not specific to FROST, but FROST adds another reason to treat extension permissions carefully.

Privacy browsers make different choices. Brave documents a mix of API blocking, modification, and randomization to make browser instances harder to link. Firefox offers fingerprinting protection against known and suspected fingerprinters and an advanced resist-fingerprinting setting that may affect compatibility. Tor Browser aims for a stronger anonymity set by making users look more alike and isolating state.

A FROST-specific defense would need to address storage timing rather than only stable identifiers. Randomizing canvas output does not stop SSD contention measurement. Blocking known fingerprinting scripts may catch reused code but not custom attacks. Reducing timer precision helps, but the result depends on implementation. Disabling OPFS would be strong but may break modern web apps.

The extension ecosystem therefore mirrors the browser’s dilemma: defenses that preserve compatibility may be partial, while stronger defenses may break useful software. Users choosing privacy tools are often making that trade already. FROST adds one more signal to the list.

The second compact view of practical exposure

Practical risk by environment

The table is intentionally conservative. The risk rises when a malicious page stays open during valuable target activity and when the attacker can train against a predictable environment. It falls when sessions are separated, scripts are constrained, timers are degraded, or OPFS behavior is limited.

Native app comparisons cut both ways

Some readers may ask whether this is simply the cost of making the web competitive with native apps. Native apps can already perform storage timing attacks if they run on the device. The difference is distribution and trust. Users expect native apps to require installation, operating system permissions, code signing, reputation signals, endpoint controls, or app-store review. A web page is cheaper to deliver and easier to close, but also easier to lure someone into visiting.

The web’s security model is built on low-friction navigation. Clicking a link should not feel like installing software. That is why browsers are cautious about exposing local device capabilities. The platform grants power gradually: geolocation prompts, camera prompts, file pickers, notifications, WebUSB prompts, and related permission surfaces. OPFS slipped into a quieter category because it does not expose user-visible files. FROST shows that local power can matter even when the files are self-created.

Native apps also have broader telemetry and detection surfaces. Endpoint tools can monitor a suspicious executable performing unusual disk operations. Browser-based attacks hide inside the browser’s expected behavior. A corporate EDR may see Chrome or Firefox reading profile storage, not a suspicious binary. That makes web-delivered side channels attractive for stealthy reconnaissance.

At the same time, browsers have defenses native apps lack. Browser vendors can update quickly, restrict APIs, throttle background tabs, partition state, and apply origin-based policies. A fix in Chrome, Firefox, Safari, or Edge can protect many users without requiring every website to change. The web also has standards review and privacy groups that can adjust future APIs.

The web is not becoming unsafe because it becomes more capable. It becomes harder to secure because capability erases the clean boundary between page and application. FROST is one case study in that shift.

The storage stack has become part of browser privacy

For years, web privacy debates centered on cookies, third-party trackers, local storage, canvas fingerprinting, browser headers, and IP addresses. Storage was mainly about identifiers: a site places a value on the device and reads it later. OPFS adds a more physical storage question: not only what a site stores, but what storage operations reveal through timing.

This changes the mental model. A storage API has at least four privacy dimensions:

First, direct data confidentiality: which origin can read which stored objects. OPFS performs well here by design because each origin gets private storage.

Second, persistence: how long stored data lasts, how users clear it, whether it survives restarts, and whether it is evicted under pressure. Browser storage quotas and eviction rules address this dimension.

Third, user visibility and control: whether users see prompts, manage stored data, understand which site stored it, and can remove it. OPFS is less visible than user-selected files, though browsers may expose site data controls and developer tools.

Fourth, side-channel observability: whether a site’s storage operations reveal activity elsewhere through shared resources. FROST makes this dimension unavoidable.

Most browser UI covers the first three only partially and the fourth barely at all. Users may see that a site stored data, but not that it performed timing measurements. Browser privacy panels may show cookies and storage sizes, not storage access patterns. Developer tools can reveal more, but not in a consumer-facing way.

A modern browser privacy model needs to treat storage as behavior, not only as data. An origin that creates, reads, writes, deletes, and times large files is doing something worth classifying, even if every byte belongs to that origin.

SSD side channels fit a larger hardware pattern

FROST belongs to a family of attacks based on contention. Shared resources leak because one user’s activity changes another user’s measurements. CPU cache attacks measure cache occupancy. Bus attacks measure transfer delays. GPU attacks measure graphics resource contention or performance counters. File system attacks measure synchronization delays. SSD attacks measure storage latency.

The “Secret Spilling Drive” paper studied commodity SSD contention and showed website fingerprinting and covert channels using native-style access. Other work has explored SSD host memory buffers, file-system synchronization, GPU interconnects, and browser cache attacks. The common theme is that high-performance shared systems rarely provide perfect noninterference.

Hardware vendors often improve throughput through shared caches, queues, speculation, compression, deduplication, and scheduling. Those optimizations reduce average latency but may create measurable differences. Security teams then try to hide, partition, or blur those differences. Perfect partitioning is expensive. Noise hurts performance. Disabling features wastes hardware. Side-channel defense is full of tradeoffs because the leak often comes from the same mechanism that makes the system fast.

SSDs are especially interesting because they sit between persistent data and performance optimization. Their internals are complex. Flash translation layers map logical blocks to physical pages. Controllers schedule requests. Caches hide latency. Some drives use host memory buffers. Operating systems add file systems and page caches above them. A browser storage API sits several layers higher, yet the timing signal can still travel upward.

FROST is a reminder that web privacy depends partly on hardware behavior users never see and browsers do not fully control. The browser can mediate API access, but it cannot rewrite every SSD controller. That makes browser-level mitigations more likely to focus on access patterns, timing, throttling, and permissions rather than eliminating the underlying physical effect.

The open-world result is the more important number

Closed-world classification is useful for proving signal strength, but open-world classification better reflects real browsing. In a closed-world top-50 setup, the classifier assumes the user visited one of the 50 monitored sites. In an open-world setup, the model must decide whether a trace belongs to a monitored site or to the wider “other” category. False positives matter. If an attacker wrongly labels many unmonitored sites as sensitive targets, the signal loses value.

The FROST paper reports 86.95% macro-averaged F1 for open-world top-50 website fingerprinting using OPFS. That is a serious number because it suggests the model can distinguish monitored sites from a wider background with meaningful success in the experiment. The paper’s Figure 6 caption also reports open-world accuracy of 96.72% for the website-fingerprinting confusion matrix.

Open-world performance still does not mean universal transfer. The monitored set is fixed. The background set is selected. The environment is controlled. A real attacker would need to choose targets with valuable traces and train models that survive differences in user machines. But open-world success is the step that moves a side channel from lab curiosity toward plausible abuse.

The application fingerprinting result may be more relevant for targeted attacks. Applications often produce distinctive launch or activity patterns. If a target organization uses a known app set, and if the attacker can train on similar machines, app inference may offer reconnaissance value. The paper’s application list includes ordinary macOS apps such as Contacts, Music, Calculator, App Store, Keynote, TV, Weather, System Settings, Maps, and Safari, with a reported 95.83% F1 score in the closed-world setting.

The larger lesson is that classification framing matters as much as raw accuracy. A tracker interested in broad identity may need stable signals across sessions. A spy interested in one sensitive app may need only a yes/no inference. A fraud system may use coarse categories. A malicious site may adapt content based on probabilistic guesses. Different abuse cases have different thresholds.

The attack does not need third-party cookies

One reason browser fingerprinting persists is that it does not rely on the storage mechanism users and browsers have fought over most: third-party cookies. A first-party malicious site can run code when visited. A third-party script embedded in a first-party site may run depending on browser and site policy. A tracking system may combine server-side data with client-side measurements that are not cookies.

Firefox’s public fingerprinting explanation notes that browser fingerprinting can work without cookies and is harder to detect and reset. That is the policy concern behind anti-fingerprinting systems. Cookies create a stored identifier that users can clear or block. Fingerprints and side-channel traces may be regenerated on demand.

FROST is not exactly a stable fingerprint of the device. It is closer to an activity fingerprinting method. Still, it lives in the same cookieless world. A site could run the measurement during a session, infer behavior, and send a compact result to a server. Clearing cookies afterward would not erase the inference already made. Blocking third-party cookies would not stop a first-party malicious page. Consent banners may not mention the technique.

This is why regulators and browser vendors increasingly talk about “tracking technologies” rather than only cookies. The ICO uses “storage and access technologies” as a broader term. The EDPB guidance is written around storage or access to terminal equipment, not around one cookie format.

The post-cookie web does not automatically become a private web. It may become a web where tracking shifts into APIs, inference, server-side joins, device signals, and side channels. FROST is a technical example of that migration pressure.

News coverage should avoid two opposite mistakes

The first mistake is sensationalism. A headline that implies websites can now read your SSD files would be wrong. FROST does not give a page direct access to private files. It does not let JavaScript browse the user’s disk. OPFS remains origin-private. The attack is based on timing and inference. That distinction matters because exaggerated claims make serious research easier to dismiss.

The second mistake is minimization. A response that says “it only leaks metadata” or “it only works in a lab” misses why the result matters. Many privacy harms are metadata harms. Many real attacks start as lab techniques. Browser vendors need research like this precisely because deployment conditions can change. A side channel that is inconvenient today may become easier with faster hardware, better models, more standardized devices, or careless API design.

Ars Technica’s framing captures the practical concern: websites have a new way to spy by measuring subtle interactions with SSDs, and the technique can monitor other sites and apps in tested settings. Tom’s Hardware similarly emphasizes that the attack uses a browser API, needs no permissions or user interaction after visiting the page, and identifies websites and apps with strong reported scores on a test Mac.

The best public reading is precise: FROST is a newly described browser side channel that uses OPFS storage timing to infer user activity from SSD contention. It is not known from the cited reporting to be exploited in the wild. It is not a file-reading bug. It is a privacy and platform-design warning with credible experimental results.

That precision is not pedantry. It determines the right fix. If people think FROST reads files, they will demand file permissions. If people understand that FROST measures contention, they will ask about timing, storage performance, background execution, API gating, and side-channel review.

OPFS should not be treated as a failed feature

It would be easy to respond by calling OPFS a mistake. That would be too shallow. OPFS solves real problems for the web. It lets apps store large local data privately to an origin, work offline, avoid unnecessary uploads, and use file-like access patterns. Removing or crippling it would harm developers and users who rely on local-first web applications.

The better response is to treat OPFS as a powerful feature that needs a threat model matching its power. The browser already does this elsewhere. Camera access is useful, so it gets permission prompts. Clipboard access is useful, so it is constrained. File pickers are useful, so they involve user activation. SharedArrayBuffer is useful, so it is gated behind cross-origin isolation. OPFS may need more graduated controls for high-risk usage rather than a single all-or-nothing treatment.

A small note-taking app storing text files should not face the same barriers as a page creating a huge file and performing high-frequency random reads while hidden in the background. A local database should not be punished for legitimate work, but the browser can still ask whether a pattern resembles measurement rather than application storage. Distinguishing those cases is hard, but browsers already use heuristics for pop-ups, autoplay, notifications, storage eviction, and background throttling.

The goal should be to preserve OPFS as application infrastructure while making it worse as a sensor. That may require browser experiments, standards discussion, telemetry from real apps, and collaboration with researchers. A quick patch may not exist.

The FROST paper itself discusses possible defenses and argues that direct low-latency file-system access from the browser can threaten privacy. The authors suggest additional protections such as a permission prompt for OPFS as one mitigation path.

Permission prompts are both tempting and flawed

A permission prompt is the most visible defense. It creates user awareness and gives browsers a clean policy boundary. If a site wants OPFS, ask. If the user declines, no storage-timing probe. The FROST authors point to permission prompts for OPFS as a possible mitigation.

The problem is prompt fatigue. Users already face cookie banners, notification prompts, location prompts, account pop-ups, newsletter modals, passkey prompts, and app install banners. Another prompt may become noise. Worse, a vague OPFS prompt may mislead. Users may think “private file system” means safer, not riskier. They may allow it for games, editors, and productivity apps without understanding side channels.

A better permission model could be tiered. Small storage use without high-frequency timing might remain promptless. Large allocations, persistent storage, background access, or patterns consistent with measurement could require user activation or a visible indicator. The browser could phrase the prompt around local storage size and performance access, not file access. Even then, explaining “this may expose timing information about your device” in consumer language is difficult.

Permission prompts also do little for trusted third-party scripts embedded in a site the user already trusts. If a bank, newsroom, or workplace app requests storage for a legitimate feature, a third-party tag inside that page may benefit unless properly isolated. The permission applies at the origin level, while abuse may come from supply-chain code.

Prompts are accountability tools, not complete side-channel defenses. They should be paired with technical limits that reduce measurement quality. Otherwise, the platform shifts responsibility to users who cannot reasonably evaluate the risk.

Detection will need browser-native telemetry

Detecting FROST-like behavior outside the browser is hard. Operating systems and endpoint tools see browser I/O, not necessarily which origin initiated which OPFS reads. Network tools see outbound data, not local timing loops. Website owners see their own code only if they audit it. Users see little.

Browsers, by contrast, can know origin, storage API calls, page visibility, worker usage, timing API calls, read patterns, file sizes, and background state. That makes the browser the best place to detect abuse. A browser could flag an origin that creates a large OPFS file and performs repeated random reads with high-frequency timing while no user-visible task is underway. It could degrade timers for that origin, throttle storage, or surface a privacy warning.

The risk is false positives. Some legitimate apps perform random reads. Databases, search indexes, development tools, games, map engines, and media apps may access local files unpredictably. A browser that throttles them may damage the very class of web apps OPFS supports. A browser that only warns may train users to ignore warnings.

Detection may need context. Is the page visible? Did the user interact with it? Is it installed as a web app? Is it using known database libraries? Does it upload trace-like data? Is it embedded as a third-party frame? Is it running from a domain known for ads or tracking? Is the pattern continuous after the visible task ends? These signals could reduce false positives but raise governance questions.

A browser-side abuse detector would be a privacy system, not a classic antivirus rule. It would need careful transparency, appeal paths for developers, and test suites. The web platform has done this kind of work before with pop-up blocking, autoplay policies, abusive notification prompts, mixed-content blocking, and safe browsing. FROST suggests storage behavior may join that list.

Site owners need a privacy bill of materials

Software supply-chain security has pushed organizations toward bills of materials: which components are in the product, where they come from, and what risk they carry. Web privacy needs a similar inventory for client-side code. A site should know which scripts run, which APIs they call, which data they collect, which vendors receive it, and which user controls apply.

FROST expands the API inventory. A privacy bill of materials should ask whether scripts use OPFS, IndexedDB, Cache API, local storage, high-resolution timers, WebAssembly, WebGL, audio APIs, canvas reads, device memory, hardware concurrency, font access, performance entries, or other fingerprintable surfaces. Not every use is bad. The point is visibility.

For publishers and e-commerce sites, this may sound heavy. But tag sprawl is already a security and performance problem. Third-party scripts slow pages, create supply-chain risk, and complicate compliance. A storage-timing side channel adds privacy harm. The cost of knowing what runs on a page is lower than the cost of explaining later why a vendor measured users’ devices.

Regulated sectors should be stricter. Health, finance, education, employment, government, and child-directed services should treat high-risk browser APIs as governance items. They should require vendor representations about fingerprinting and side-channel measurement. They should test pages with browser instrumentation. They should avoid loading advertising or broad analytics scripts inside sensitive authenticated sessions.

A website that invites third-party JavaScript into a user’s browser is delegating part of its privacy posture. FROST makes that delegation more consequential because the delegated code may observe signals outside the page’s content.

Researchers gave browser vendors an early warning

The responsible disclosure section matters. The authors did not simply publish a stunt. They disclosed to major browser vendors and documented responses. That gives vendors a chance to evaluate mitigations and gives the public a clearer picture of platform priorities.

Research disclosure is especially important for side channels because there may be no single patch. A memory bug can often be fixed by bounds checks, compiler changes, or library updates. A side channel may require API redesign, heuristics, hardware assumptions, and standards debate. Public research creates pressure and shared vocabulary.

The paper’s acceptance to DIMVA 2026, as listed by Graz University of Technology’s ISEC publication pages and author pages, also places it in the security research pipeline rather than rumor.

The best outcome is not a vendor blame cycle. Google, Apple, Mozilla, Microsoft, Brave, and other browser makers all face variants of this problem. If one browser disables useful APIs too aggressively, web apps may break or users may switch. If one browser leaves privacy leaks open, users suffer. Standards-level coordination is valuable because it reduces the penalty for doing the safer thing.

FROST should become a test case for side-channel review of high-performance web APIs. Browser teams can reproduce it, measure mitigations, compare platform differences, and feed lessons back into OPFS and future APIs.

The web is becoming a local computing platform

The web’s center of gravity has shifted from pages to applications. Users edit photos, code software, join video calls, manage databases, design products, play games, write documents, train models, and run business workflows in the browser. That shift is not reversible. The browser is the most widely distributed application runtime in the world.

Local computing in the browser has benefits. It reduces server dependence, supports offline use, lowers latency, protects some data from cloud upload, and makes powerful tools accessible without installation. OPFS belongs to that story. So do WebAssembly, WebGPU, service workers, persistent storage, and installable web apps.

The cost is that browsers now expose more of the machine. A document viewer could be secured mostly through parsing, scripting boundaries, and network policy. A local computing platform must manage files, memory, graphics, sensors, storage, threads, and performance. Every one of those areas has side channels. Native operating systems have wrestled with them for decades. The web inherited the problem as it inherited the power.

FROST is not an argument against the capable web. It is an argument for a more honest capable web. Users should know when sites get local resources. Developers should understand side-channel risk. Browser vendors should review performance APIs as privacy surfaces. Standards bodies should require abuse analysis for features that touch shared hardware.

The web can still be safer than native apps because it has centralized browser mediation and rapid updates. But that advantage only holds if browsers treat indirect measurement as a first-class risk.

A realistic mitigation stack would be layered

No single defense will likely stop every FROST-like attack while preserving OPFS. A realistic mitigation stack would combine several weaker controls.

Timer controls can reduce measurement precision, especially outside user-activated and isolated contexts. Storage controls can limit large OPFS files, high-frequency random reads, or background access. Scheduling changes can reduce observability of contention. Browser heuristics can detect measurement-like patterns. Permissions or prompts can add visibility for high-risk use. Site owners can reduce third-party scripts. Users can separate sensitive browsing. Privacy browsers can offer stricter modes.

The difficulty is choosing defaults. Most users will not configure advanced privacy settings. Most developers will use APIs as documented. Most sites will add third-party scripts if revenue or analytics demand it. Defaults decide the real privacy level. If OPFS remains fully available with high-quality timing in ordinary browsing, attackers can experiment. If browsers add friction only in strict privacy modes, most users remain exposed.

A good default may be contextual. A foreground app with clear user interaction and obvious storage need gets smoother OPFS. A background tab with no recent interaction performing random reads gets throttled. A third-party iframe gets stricter limits. Cross-origin isolated contexts get powerful timers only when storage side-channel patterns are absent or degraded. Installed web apps get more capability than drive-by pages. Sensitive browser modes disable OPFS or coarsen timing aggressively.

The right defense is probably not “block OPFS.” It is “make drive-by measurement unreliable.” If attackers cannot collect clean traces at scale from ordinary pages, the abuse value drops while legitimate apps remain possible.

This will require empirical work. Browser vendors need to test real apps, reproduce FROST variants, and measure how mitigations affect accuracy. Researchers can help by publishing benchmarks and attack code responsibly. Standards groups can define privacy expectations. Developers can report breakage from experimental defenses.

The public should separate threat from exploitability

A threat is a plausible path to harm. Exploitability is how easily that path can be used in practice. FROST is a credible threat because it demonstrates a remote browser side channel using a standard API. Its exploitability is conditional because real-world deployment depends on environment, training, timing, browser behavior, and user activity.

This distinction helps users make sane choices. It is not necessary to panic and stop using modern browsers. It is also unwise to ignore the research because it sounds academic. Browser side channels have shaped real platform changes before. Spectre forced browsers to rethink timers, SharedArrayBuffer, and process isolation. Cache attacks influenced research into timer restrictions and isolation. Fingerprinting defenses are now standard parts of privacy browsers.

For most users, the best near-term change is behavioral separation. Do not keep random tabs open while doing sensitive tasks. Use privacy protections. Avoid sketchy sites. Clear site data. Consider a separate profile or browser for banking, health, work, and secure messaging. These steps are imperfect but reduce the window in which a malicious page can measure other activity.

For developers and site owners, the best near-term change is script discipline. Know what code runs. Remove unnecessary vendors. Use CSP. Question high-risk API use. Keep sensitive pages lean. Do not assume that privacy risk comes only from cookies.

For browser vendors, the best near-term change is measurement. Reproduce FROST across hardware, operating systems, browsers, and timer settings. Test mitigations publicly where possible. Treat OPFS timing as a privacy surface. Give enterprise administrators and privacy-focused users controls if broad defaults take time.

The story is not that websites suddenly own your SSD. The story is that the web platform exposed enough SSD behavior for a page to infer more than users expect.

FROST changes the meaning of browser storage

Browser storage used to feel like a container. A site put data in a box; the browser kept other sites out of that box; users could clear the box. OPFS still behaves like a container for direct access. FROST shows it also behaves like a stethoscope placed on the storage stack.

That shift should change documentation, privacy reviews, and user expectations. “Private to the origin” should be paired with “not a permission to read your files” and, where relevant, “high-performance local storage may expose timing side channels.” Developers do not need alarmist warnings on every API page, but they do need honest threat models.

It should also change how newsrooms cover browser privacy. The most interesting tracking techniques are no longer only cookies and pixels. They are subtle interactions between APIs and hardware. The next privacy story may come from GPU queues, local AI accelerators, compression timing, memory pressure, or background scheduling. Readers need explanations that are specific enough to avoid fear and clear enough to show why the risk is real.

FROST is a small name for a large pattern. The browser is becoming an operating environment. Operating environments leak. The web’s promise is that the browser mediates the leak better than a random native app ecosystem. Keeping that promise requires treating side channels as product issues, not only research curiosities.

The safest interpretation is this: FROST does not break the browser sandbox, but it shows that the sandbox has acoustics. A malicious page may not enter the room next door. It may still hear enough through the wall to guess what is happening there. That is the privacy problem browser makers now need to reduce.

Questions readers are asking about SSD timing and browser spying

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

FROST: Fingerprinting Remotely using OPFS-based SSD Timing
Primary research paper describing the OPFS-based SSD timing side-channel attack, experimental setup, disclosure notes, and reported results.

Websites have a new way to spy on visitors: analyzing their SSD activity
News report summarizing the FROST research and its implications for browser privacy.

Researchers say they can spy on your browsing by measuring SSD activity through a browser API
Technology news coverage highlighting the reported website and application fingerprinting accuracy.

Origin private file system
MDN documentation explaining OPFS as an origin-private browser storage endpoint.

File System API
MDN reference for browser file system capabilities and related web APIs.

File System Standard
WHATWG standard defining file system API infrastructure used by browsers.

The origin private file system
Google web.dev article explaining OPFS design, browser storage behavior, quotas, and lack of permission prompts.

The File System Access API: simplifying access to local files
Chrome developer documentation explaining file system access concepts and OPFS-related behavior.

High precision timing
MDN documentation on high-resolution timing, reduced precision, and cross-origin isolation effects.

Aligning timers with cross-origin isolation restrictions
Chrome blog post describing timer precision changes and cross-origin isolation policy.

A guide to enable cross-origin isolation
Google web.dev guide explaining COOP, COEP, SharedArrayBuffer, and high-resolution timer requirements.

Mitigating Spectre with Site Isolation in Chrome
Google Security Blog article explaining Chrome’s Site Isolation architecture and Spectre mitigation context.

Storage quotas and eviction criteria
MDN documentation on browser storage limits, quota behavior, and eviction rules.

Storage for the web
Google web.dev article explaining browser storage categories, persistence, and eviction.

Secret Spilling Drive: Leaking User Behavior through SSD Contention
NDSS paper page for prior research on SSD contention side channels.

Secret Spilling Drive: Leaking User Behavior through SSD Contention PDF
Full research paper on SSD contention, covert channels, and website fingerprinting from native interfaces.

The HMB Timing Side Channel: Exploiting the SSD’s Host Memory Buffer
Research paper on SSD host memory buffer timing side channels and related storage leakage.

The Spy in the Sandbox: Practical Cache Attacks in JavaScript
Foundational browser side-channel research showing cache attacks from JavaScript.

Prime+Probe 1, JavaScript 0: Overcoming Browser-based Side-Channel Defenses
Research on browser-based side-channel attacks that reduce reliance on JavaScript features.

Microwalk-CI: Practical Side-Channel Analysis for JavaScript Applications
Research on detecting timing leakage in JavaScript applications.

Guidelines 2/2023 on Technical Scope of Article 5(3) of ePrivacy Directive
European Data Protection Board guidance on storage and access to information in terminal equipment.

What are storage and access technologies?
UK ICO guidance explaining PECR rules for technologies that store or access information on user devices.

Mitigating browser fingerprinting in web specifications
W3C guidance for reducing browser fingerprinting risks in web standards.

Privacy principles
W3C privacy principles for the web platform and standards development.

Same-origin policy
MDN glossary entry explaining the browser same-origin security model.

Content Security Policy
MDN guide explaining CSP as a browser-enforced mechanism for constraining what page code can do.

Fingerprinting protections
Brave documentation describing browser fingerprinting protections based on blocking, modification, and randomization.

Fingerprinting protections in Tor Browser
Tor Project documentation describing anti-fingerprinting protections such as letterboxing and first-party isolation.