I read about this a while ago and people then concluded that FROST is harder to exploit in real-world scenarios than in the lab. Still worth addressing and a fix shouldn't be too difficult, e.g. by adding small amounts of random latency to OPFS accesses. Firefox already does this with other APIs to make fingerprinting harder. Chromium doesn't because they love fingerprinting.

Honestly, I'm not thrilled with the OPFS model in general. Each page can randomly occupy part of your storage with you having no control over the process. You don't get asked. You can't even inspect the data. Even if it turns out to be useless for fingerprinting, the ability to use your storage invisibly with zero effort is not a power I want to hand out like candy in an environment that supposedly is assumed to be adversarial by default.

The only upside is that browsers do have a quota which is apparently shared between all instances of IndexedDB and OPFS. So the threat model of "use OPFS to fill up the user's entire storage" isn't plausible per se even if you have multiple tabs to attack with. Filling up the storage to evict other sites' stored data might actually work, though, and while it sounds like more of an annoyance, it might also become a step in some other attack.

Besides, quota size is entirely up to the browser; while Firefox uses 10% of total storage or 10 GB, whichever is lower, Chromium can in principle take up to 60% of total storage. When I tried, both a Firefox-based browser and a Chromium-based one had quotas of exactly 10 GB; I suspect that my distro's packagers configured the latter when the built the browser package.