I can't wait to use this in my web applications. Finally a way to build proper tools in the browser.
The "Origin private file system" that this story links to is just like the infamous IndexDB. Something that the user cannot backup, cannot use in other software and that is only kept around for as long as FireFox feels like.
I've heard Firefox keeps OPFS data in browser as long as there's enough space (which can be checked from JS). It's been reliable from my experience, but backup is still necessary by saving to remote server or export as local file. Safari has a stricter strategy and removes OPFS data and local storage more aggressively, for example, if a site domain hasn't been visited in 7 days.
On the File System Access API, it seems doubtful that Mozilla will ever implement it in a useful way.
> Mozilla's Position
> There's a subset of this API we're quite enthusiastic about (in particular providing a read/write API for files and directories as alternative storage endpoint), but it is wrapped together with aspects for which we do not think meaningful end user consent is possible to obtain (in particular cross-site access to the end user's local file system). Overall we consider this harmful therefore, but Mozilla could be supportive of parts, provided this were segmented better.
Browsers have existing file APIs that programmers could use but don't. To reiterate a comment from the last time this came up:
> You could literally run the Golang compiler in your browser if you wanted to[...] A lot of the stuff that people think they need Chrome's proposed filesystem APIs for are not actually things they need.
Can't imagine a worse alternative. The filesystem api is really good. For example, I use the google office suite entirely offline through the official extension that uses the filesystem api. You can edit a local file just like that.
Same goes for photopea.
You can't seriously suggest manual save as an alternative. Ctrl+S, choose file, do you want to overwrite, yes. That's way too much friction, come on.
Call me old-fashioned, but I don't want browsers to alter the files I've downloaded after I downloaded them. Chrome gives absolutely no indication that it can still access the files I've "saved".
Seems that Mozilla is detached from reality, not only because of this, but they also refuse to implement other APIs like WebUSB providing bizarre claims about security at the same time neglecting valid arguments about web apis being safer than native apps..
I've had a couple webapps where I needed to use the FS API (which allows users to provide real, accessible folders to a webapp, unlike OPFS).
I can't understand why anyone would want to use OPFS or what problems it solves that a slim interface over IndexDB wouldn't provide. The only use I've had for it has been a almost-ok substitute for the actual FS API (given its the same interface), but since the goal is to allow users to have easy access to your webapp's data, it has to be paired with a cumbersome import/export feature for browsers that only have OPFS.
I guess it's probably more performant for FS-like queries (like listing the contents of a directory...), but that performance benefit (for me at least) seems secondary to giving users control over the data.
The OPFS is used in the online version of Photoshop to allow editing large photos without having the entire file (and undo history) loaded into working memory.
> To summarize how the OPFS differs from the user-visible file system:
> * The OPFS is subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism (for example IndexedDB API). You can access the amount of storage space the OPFS is using via navigator.storage.estimate().
> * Clearing storage data for the site deletes the OPFS.
> * Permission prompts and security checks are not required to access files in the OPFS.
> * Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user.
> * It also has a set of synchronous calls available (other File System API calls are asynchronous) that can be run inside web workers only so as not to block the main thread.
This feels a lot like giving companies a way to store data on my device without me being in control of that data. If your web app is going to store data, I want the power to audit that data, not have the browser go "oh, sorry, can't let you do that, that would hurt someone else's bottom line".
They already do this with cookies, local storage, IndexDB and WebSQL. OPFS is not changing anything - I'm pretty sure it'll be visible in Developer Tools just like other data storages.
The issue is that browser vendors are making design decisions that do not respect power users, but this issue is way bigger and more complicated (and quite different) than some data storage oddities. There are only a few browsers out there (forks don't matter, they don't change architecture), and no single one of them has modular design with user-replaceable parts talking over well-defined interfaces, classic UNIX-way style.
If anything, inability of a website to put a known-content file in user-accessible file system is a security feature. If a website would be allowed to place a file with arbitrary content under a well-known or mostly-known location somewhere in user's home directory, that could lead to unwanted consequences.
You didnt read the website. It says that you wont be able to find the files on your disk, even when searching for the contents. So Firefox will be actively encrypting / obfuscating them.
That's not the case for localStorage or cookies or any other current option, because all of them you can access both on the disk and via devtools.
I'm sorry? I did, and I just skimmed over it again, and I still don't see where it says anything along the lines of "even when searching for the contents".
The only relevant piece I see in the article is this (emphasis mine):
> Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user.
And that matches how cookies and localStorage works. They aren't files either, they're in a SQLite database somewhere out there.
Can you please give me a quote where it says so?
Upd: There's Chrome (web.dev) article linked from MDN that explicitly mentions a way for end-user to browse this filesystem: https://web.dev/articles/origin-private-file-system#debug_th... - I'm pretty sure Firefox has (or will have, idk how mature is this standard) something similar.
How those files are stored on disk is an implementation detail. All article says that user should not expect them to match their local filesystem conventions, hinting that it's probably going to live in some kind of a database rather than match host filesystem conventions.
Upd2: I've checked out the demo (https://sqlite-wasm-opfs.glitch.me/) and it looks like, indeed, Firefox is missing an ability to introspect the storage at the moment. Or at least I don't see anything in DevTools on Firefox 131. This is disappointing and concerning, but I strongly suspect it's a bug/missing feature rather than a deliberate design decision.
Upd3: I see that demo's site data near-pristine content-wise under ~/.mozilla/firefox/$profile/storage/default/https+++sqlite-wasm-opfs.glitch.me/fs/... While filenames are nonsensical, the SQLite3 demo database (with that single table "t") that's created in OPFS is accessible in my host machine's filesystem verbatim:
$ sqlite3 KF3XI6X7GVF3O6IT3QGODMSZ4OMH56DTTUBOK23MNTB6ODM5HWEA
SQLite version 3.45.3 2024-04-15 13:34:05
Enter ".help" for usage hints.
sqlite> .tables
t
sqlite> SELECT * FROM t LIMIT 3;
20|40
21|42
22|44
Note that if it shows up in the dev tools "Storage" tab, then that's fine, that's how you audit cookies and local/sessionStorage just fine already. But from what I can tell, part of the "no no, we call it private for a reason" is that they're not getting exposed that way. If finding a sqlite3 db and manually working in that is the only way to audit the data, that's a dark pattern right there.
Anything that makes the web platform more powerful is a good thing. The web is a secure, sandboxed platform, but it's also an open platform. Screw Apple and their extortions, develop web apps instead.
From my perspective, the biggest flaw in FireFox is that it does not support the File System Access API.
Because with it, we can offer users to hold their data natively on their devices. Instead of storing everything in the cloud.
Chrome on the desktop supports it. Here is a demo:
https://googlechromelabs.github.io/text-editor/
A text editor that works just like a native application.
And mobile support is also in the making:
https://issues.chromium.org/issues/40101963
I can't wait to use this in my web applications. Finally a way to build proper tools in the browser.
The "Origin private file system" that this story links to is just like the infamous IndexDB. Something that the user cannot backup, cannot use in other software and that is only kept around for as long as FireFox feels like.
> kept around for as long as FireFox feels like
I've heard Firefox keeps OPFS data in browser as long as there's enough space (which can be checked from JS). It's been reliable from my experience, but backup is still necessary by saving to remote server or export as local file. Safari has a stricter strategy and removes OPFS data and local storage more aggressively, for example, if a site domain hasn't been visited in 7 days.
On the File System Access API, it seems doubtful that Mozilla will ever implement it in a useful way.
> Mozilla's Position
> There's a subset of this API we're quite enthusiastic about (in particular providing a read/write API for files and directories as alternative storage endpoint), but it is wrapped together with aspects for which we do not think meaningful end user consent is possible to obtain (in particular cross-site access to the end user's local file system). Overall we consider this harmful therefore, but Mozilla could be supportive of parts, provided this were segmented better.
https://mozilla.github.io/standards-positions/#native-file-s...
Browsers have existing file APIs that programmers could use but don't. To reiterate a comment from the last time this came up:
> You could literally run the Golang compiler in your browser if you wanted to[...] A lot of the stuff that people think they need Chrome's proposed filesystem APIs for are not actually things they need.
<https://news.ycombinator.com/item?id=41176674>
Can't imagine a worse alternative. The filesystem api is really good. For example, I use the google office suite entirely offline through the official extension that uses the filesystem api. You can edit a local file just like that.
Same goes for photopea.
You can't seriously suggest manual save as an alternative. Ctrl+S, choose file, do you want to overwrite, yes. That's way too much friction, come on.
Ok but that outlines a miserable user experience.
Agreed - the picker APIs are essential. Chrome Developers did a blog about how we use it in Construct, our browser-based game development software: https://developer.chrome.com/blog/how-construct3-uses-the-fi...
As it says - 65% of users save to local files. It's what people want.
Call me old-fashioned, but I don't want browsers to alter the files I've downloaded after I downloaded them. Chrome gives absolutely no indication that it can still access the files I've "saved".
> Chrome gives absolutely no indication ...
https://imgur.com/a/XOLvosa
And this is after a prompt to give access, of course.
Seems that Mozilla is detached from reality, not only because of this, but they also refuse to implement other APIs like WebUSB providing bizarre claims about security at the same time neglecting valid arguments about web apis being safer than native apps..
Why even bother to sandbox the browser if it can scribble all over my USB devices?
it can't, you have to pick which device it can use.
I've had a couple webapps where I needed to use the FS API (which allows users to provide real, accessible folders to a webapp, unlike OPFS).
I can't understand why anyone would want to use OPFS or what problems it solves that a slim interface over IndexDB wouldn't provide. The only use I've had for it has been a almost-ok substitute for the actual FS API (given its the same interface), but since the goal is to allow users to have easy access to your webapp's data, it has to be paired with a cumbersome import/export feature for browsers that only have OPFS.
I guess it's probably more performant for FS-like queries (like listing the contents of a directory...), but that performance benefit (for me at least) seems secondary to giving users control over the data.
The OPFS is used in the online version of Photoshop to allow editing large photos without having the entire file (and undo history) loaded into working memory.
https://developer.chrome.com/blog/how-photoshop-solved-worki...
> To summarize how the OPFS differs from the user-visible file system:
> * The OPFS is subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism (for example IndexedDB API). You can access the amount of storage space the OPFS is using via navigator.storage.estimate().
> * Clearing storage data for the site deletes the OPFS.
> * Permission prompts and security checks are not required to access files in the OPFS.
> * Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user.
> * It also has a set of synchronous calls available (other File System API calls are asynchronous) that can be run inside web workers only so as not to block the main thread.
This feels a lot like giving companies a way to store data on my device without me being in control of that data. If your web app is going to store data, I want the power to audit that data, not have the browser go "oh, sorry, can't let you do that, that would hurt someone else's bottom line".
They already do this with cookies, local storage, IndexDB and WebSQL. OPFS is not changing anything - I'm pretty sure it'll be visible in Developer Tools just like other data storages.
The issue is that browser vendors are making design decisions that do not respect power users, but this issue is way bigger and more complicated (and quite different) than some data storage oddities. There are only a few browsers out there (forks don't matter, they don't change architecture), and no single one of them has modular design with user-replaceable parts talking over well-defined interfaces, classic UNIX-way style.
If anything, inability of a website to put a known-content file in user-accessible file system is a security feature. If a website would be allowed to place a file with arbitrary content under a well-known or mostly-known location somewhere in user's home directory, that could lead to unwanted consequences.
If it doesn't change anything why is it needed? It clearly changes something and I'm not convinced it's for my, the user's, benefit.
You didnt read the website. It says that you wont be able to find the files on your disk, even when searching for the contents. So Firefox will be actively encrypting / obfuscating them.
That's not the case for localStorage or cookies or any other current option, because all of them you can access both on the disk and via devtools.
I'm sorry? I did, and I just skimmed over it again, and I still don't see where it says anything along the lines of "even when searching for the contents".
The only relevant piece I see in the article is this (emphasis mine):
> Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user.
And that matches how cookies and localStorage works. They aren't files either, they're in a SQLite database somewhere out there.
Can you please give me a quote where it says so?
Upd: There's Chrome (web.dev) article linked from MDN that explicitly mentions a way for end-user to browse this filesystem: https://web.dev/articles/origin-private-file-system#debug_th... - I'm pretty sure Firefox has (or will have, idk how mature is this standard) something similar.
How those files are stored on disk is an implementation detail. All article says that user should not expect them to match their local filesystem conventions, hinting that it's probably going to live in some kind of a database rather than match host filesystem conventions.
Upd2: I've checked out the demo (https://sqlite-wasm-opfs.glitch.me/) and it looks like, indeed, Firefox is missing an ability to introspect the storage at the moment. Or at least I don't see anything in DevTools on Firefox 131. This is disappointing and concerning, but I strongly suspect it's a bug/missing feature rather than a deliberate design decision.
Upd3: I see that demo's site data near-pristine content-wise under ~/.mozilla/firefox/$profile/storage/default/https+++sqlite-wasm-opfs.glitch.me/fs/... While filenames are nonsensical, the SQLite3 demo database (with that single table "t") that's created in OPFS is accessible in my host machine's filesystem verbatim:
Note that if it shows up in the dev tools "Storage" tab, then that's fine, that's how you audit cookies and local/sessionStorage just fine already. But from what I can tell, part of the "no no, we call it private for a reason" is that they're not getting exposed that way. If finding a sqlite3 db and manually working in that is the only way to audit the data, that's a dark pattern right there.
I'd be happy to be wrong about that, though.
For some reason it's not visible in DevTools' "Storage" tab (Firefox 131.0.2). I strongly suspect it's negligence rather than malice, though.
I'm definitely turning it off if there's a toggle in about:config
It's hard to imagine that folks at Firefox came up with this idea organically.
To me it feels like this is a Google initiative in order to allow more DRM/Ad-Tracking stuff and they're testing the waters.
Mozilla bought an ad company: https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...
They're in the same business now.
Anything that makes the web platform more powerful is a good thing. The web is a secure, sandboxed platform, but it's also an open platform. Screw Apple and their extortions, develop web apps instead.