[HN Gopher] Origin private file system
___________________________________________________________________
Origin private file system
Author : thunderbong
Score : 40 points
Date : 2024-11-14 16:24 UTC (6 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| hoten wrote:
| 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.
| tommiegannert wrote:
| > 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.
| jamesgeck0 wrote:
| 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...
| mg wrote:
| 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.
| AshleysBrain wrote:
| 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.
| zb3 wrote:
| 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..
| DrillShopper wrote:
| Why even bother to sandbox the browser if it can scribble all
| over my USB devices?
| exe34 wrote:
| it can't, you have to pick which device it can use.
| lioeters wrote:
| > 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...
| jeroenhd wrote:
| 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".
| hoten wrote:
| > Chrome gives absolutely no indication ...
|
| https://imgur.com/a/XOLvosa
|
| And this is after a prompt to give access, of course.
| cxr wrote:
| 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>
| TheRealPomax wrote:
| 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".
| DrillShopper wrote:
| I'm definitely turning it off if there's a toggle in
| about:config
| drdaeman wrote:
| 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 wrote:
| 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 wrote:
| 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
| TheRealPomax wrote:
| 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 wrote:
| 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.
| behringer wrote:
| 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.
| bflesch wrote:
| 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.
| timschmidt wrote:
| Mozilla bought an ad company:
| https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...
|
| They're in the same business now.
| zb3 wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-14 23:00 UTC)