AccessHandles for the Origin Private File System

[fivedots]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: AccessHandles for the Origin Private File System
• Specification or proposal URL: https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
• Mozillians who can provide input: @annevk

Other information

We've requested a position on a previous iteration of this API: #481 . This new proposal is a response to feedback that Storage Foundation seemed to duplicate existing functionality and should be integrated into the File System Access API.

Thank you!

[fivedots]

(@annevk, since he has provided feedback before)

Hello, has there been any news on this request?

[domenic]

For what it’s worth, I’m pretty happy with this new proposal, in terms of how it addresses my concerns at WICG/storage-foundation-api-explainer#8. It builds well on OPFS, with a streams-based interface for the mainline use cases, and a worker-only sync extension that is minimal (i.e. only sync read/write; truncate/getSize/flush/close remain async) and symmetric with the streams-based async version. I hope our colleagues at Mozilla feel similarly :)

[annevk]

To set some context, we consider the File System Access API harmful (see #154, #545) because of the capabilities that involve granting direct access to the user's file system. That set of APIs also offers an Origin Private File System. We'd consider that Origin Private File System worth prototyping if it were to be split from the File System Access API.

Now this AccessHandle API in turn essentially provides a better way of manipulating files in a file system, though it's scoped to the Origin Private File System for the moment (see https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems). I continue to think it looks good and I'll ask others to take a look as well.

A thing I'm wondering about is if we were to split Origin Private File System from File System Access API and Firefox/Safari were willing to adopt that as well as this AccessHandle API, what sense would it make for us to support the "current" File System Access API way of manipulating files. As far as I can tell that would just be legacy baggage at that point. (And would that reduction in points of access to file manipulation change anything about naming (maybe) or overall API shape (seems less likely)?

[domenic]

As far as I can tell that would just be legacy baggage at that point.

My understanding (but the domain experts like @fivedots or @mkruisselbrink should confirm) is that the existing API has different tradeoffs vs. the access handle API in terms of persistance and durability. Something like, access handle does more stuff in memory so it can be faster, but then your data could get lost due to power failure? https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#what-makes-the-new-surface-fast seems to hint at that.

Whether that should really lead to two separate APIs, or whether the old API could be recast in the style of the new one with different backing semantics, is not clear to me.

[rektide]

Elsewhere, programmers have historically often gotten File-System-Access like durability by writing to a new file then renaming the new one atop the old one. The dueling standards we have now definitely feels to me like another strong example of the Extensible Web Manifesto being spot on: giving the web lower level tools like Access Handles & letting folks build higher level libraries that are File System Access like feels to me like what should have happened.

Unrelated, I want to comment on:

To set some context, we consider the File System Access API harmful (see #154, #545) because of the capabilities that involve granting direct access to the user's file system.

It hurts to hear this. There's so many cool things the web could do if it could access real files. Projects like Adobe bringing Photoshop to the web would be so much more interesting, so much more empowered, if they could work with & mesh wish a user's system. I feel like we're trying to protect users by making them unable to do anything interesting, if we take Annevk's statement as an absolute.

[fivedots]

Hey @annevk, I was wondering if this issue was ready to be closed, given the context of whatwg/sg#176 and subsequent migration to https://github.com/whatwg/fs?

[annevk]

Thanks for the reminder @fivedots! I've created #614 to establish a formal position for the File System standard. This addition to that standard can be considered worth prototyping. I don't think we need to add a separate entry for it in our dashboard, but if anyone disagrees, please speak up!

[jimmywarting]

To set some context, we consider the File System Access API harmful (see #154, #545) because of the capabilities that involve granting direct access to the user's file system.

I also thinks it hurts 😢
you are already allowed to do some stuff today to some degree, could we at least ship some parts of the features that isn't harmful? a.k.a the things that are already possible to do without the new and shiny api? you are already allowed to read files and directories out of <input type=file webkitdirectory> and recrsivly walk a directory from DataTransferItem drag and drop.

There are some differences between drag and drop and the webkitdirectory input, in that you can read a directory over and over again with datatransfer that makes it a tiny bit more superior to see if there are any file changes and don't block the thread, cuz the input will synchronously walk the directory and populate input.files with all the files and dosen't really give you any directories

So it would have been nice to have DataTransferItem.prototype.getAsFileSystemHandle but requesting write permission would not be allowed and would always throw an error when calling handle.requestPermission(...)
the handle would be read-only for just the session and not be persistent

again the showDirectoryPicker & showOpenFilePicker isn't also directly so harmful. it's still pretty useful and you can already basically do those things today without the new File System Access. The thing that you see as potentially harmful is the write access and the persistent read access to the user's file system. I think you can at least ship some features out of the file system access. you can also save files with <a download> so i don't really see why we could also allow for showSaveFilePicker either... it also allows for the client to choose the format to save the file in.

a good compromise would be to at least ship some part of the file system access but don't implement the requestPermission or saving the handles into IndexedDB if that is what is deemed as potentially harmful.

[annevk]

We plan to support the WHATWG File System Standard. And yeah, I could imagine extensions to drag & drop and copy & paste along those lines, as well as <input type=file>. Baby steps.

Anyway, that's all out-of-scope for this issue and as nobody has spoken up since my statement on Feb 11, I'm closing this.

[baughmann]

I work for a very large organization that always errs on the side of caution. Yet, we do not ship Firefox on any of our systems, and its often because of decisions like this. We simply need more features are we transition away from desktop applications. (Don't forget, desktop applications with free rein are the alternative to a browser FS sandbox).

I would humbly advise Mozilla to take the lead in guiding the implementation standards like this in a manner that is safe and beneficial to consumers rather than just sit it out. The internet needs Mozilla and Firefox to stay relevant. It does not good to hand the reins to the likes of Google and Apple.