[mtrycz2]

So it is a sandboxed, abstract filesystem, not rw access to my actual filesystem?

The first lines of the description say

> This API allows interaction with files on a user's local device, or on a user-accessible network file system.

[sgbeal]

> So it is a sandboxed, abstract filesystem, not rw access to my actual filesystem?

It's sandboxed storage which lives in your filesystem but is only available via the browser and is sandboxed on a per-HTTP-origin basis. That makes it impossible[^1], e.g., for x.y.com to sideload data into, or exfiltrate from, y.z.com. How the files are actually stored on your filesystem is not defined by the in-progress standards doc, but they are not stored as-is because doing so would open them up to security issues from out-of-browser sources, as well as potential file-locking problems from out-of-browser apps.

[^1]: Edit: as a responder points out: "impossible" for a given value of "impossible"

[madeofpalk]

> It's sandboxed storage which lives in your filesystem

It actually barely does. Spec does not require the OPFS to be browsable in the OS's filesystem. I believe all three browsers implement OPFS as a single opaque blob on disk per origin, kind of like a zip archive.

> While browsers typically implement this by persisting the contents of the OPFS to disk somewhere, it is not intended that the contents be easily user-accessible. While the browser might make it seem that there are files, they might be stored in a database or any other data structure. You cannot expect to find the created files matched one-to-one somewhere on the hard disk.

I would guess this makes it much harder to escape the sandbox filesystem if you're not actually in the filesystem in the first place.

[mikece]

It would be nice if browser offer per-origin encryption of files so that if an exploit at a future date allows x.y.com to access the files of y.z.com they would only be getting encrypted blobs (unless the encryption/decryption API is also exploited, but now we're talking about multiple exploits rather than just one).

[fangorn]

It's only impossible until someone finds a way...

[worksonmine]

> lives in your filesystem but is only available via the browser

Strange implementation if that's the case. While I don't want my browser to give a page arbitrary access to my files, a use-case I can see is sharing files between apps and websites. Say, obsidian for organizing, vim for editing and some cloud for backup.

You must have confused the part of it only being available to the browser, I don't see how that's even technically possible.

[sgbeal]

> You must have confused the part of it only being available to the browser, I don't see how that's even technically possible.

It's uses a virtual filesystem, not available _as-is_ in the filesystem to any application other than the browser or applications which implement identical access APIs. Obviously, the virtual filesystem lives in the containing filesystem.

[jrootabega]

The link/title is not quite right or was broken later by someone's silent misguided attempts to help.

The "Origin private file system" mentioned in the title is documented in this section of the linked page:

https://developer.mozilla.org/en-US/docs/Web/API/File_System...