4 ms·

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 l

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.

bflesch 2y ago
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.
- drdaeman 2y ago
  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_the_origin_private_file_system 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/ 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
  - TheRealPomax 2y ago
    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.
    - drdaeman 2y ago
      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.
      - TheRealPomax 2y ago
        Probably because this spec hasn't been accepted yet, it's still a draft.
behringer 2y ago
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.
- azornathogron 2y ago
  It just provides a different API for storage. You could say the same thing about IndexedDB being added when LocalStorage already existed - it's just a different API with some different performance characteristics. And no, it's not for the benefit of you the user, but it's not to your detriment either. It's mostly for the benefit of the web developer. (It might be good for users indirectly if web developers make good use of it)
  - behringer 2y ago
    I the user would prefer the developer use regular file storage.

bflesch 2y ago

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.

drdaeman 2y ago
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_the_origin_private_file_system 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/ 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
- TheRealPomax 2y ago
  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.
  - drdaeman 2y ago
    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.
    - TheRealPomax 2y ago
      Probably because this spec hasn't been accepted yet, it's still a draft.

behringer 2y ago

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.

azornathogron 2y ago
It just provides a different API for storage. You could say the same thing about IndexedDB being added when LocalStorage already existed - it's just a different API with some different performance characteristics. And no, it's not for the benefit of you the user, but it's not to your detriment either. It's mostly for the benefit of the web developer. (It might be good for users indirectly if web developers make good use of it)
- behringer 2y ago
  I the user would prefer the developer use regular file storage.