File System Access API

[mconca]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Native File System API
• Specification or proposal URL: https://wicg.github.io/file-system-access/ (https://github.com/WICG/file-system-access)
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

Based on activity in this Chromium bug, Google seems to be actively working towards implementing this draft spec.

This spec is a follow-on to the Writable Files proposal, which Mozilla initially classified as defer, but the last comment in the position issue suggested a new issue be opened if there is "new information such that reassessment is warranted".

[martinthomson]

This would be easier to assess if it were clearer what would be made accessible and how that access were managed. For instance, if it were possible to access arbitrary directories or files, that would be very bad. It is also possibly bad if access were granted to spaces that are shared between origins or shared with native applications. Of course, the main reason you might want to allow access to files is to enable passing of information between the web and other applications, so systems for managing access are crucial.

Working out what is safe, building systems to constrain use to fit within those bounds, and establishing norms around use are all problems that likely require significant research. We don't have any established wisdom on these topics, so I expect that will take time. The proposed spec is completely silent on this, which indicates to me that this is still very much exploratory work.

Like the other proposal, I would suggest defer until more information is available.

[dbaron]

Yeah, defer seems reasonable to me as well given that reasoning. I intend to open one issue on the repo about something else I noticed, though.

[dbaron]

Closed by #156, but it would make sense to reopen this or file a new issue if you believe there's more to evaluate.

[mkruisselbrink]

We've been working hard over the last year and a half to get the spec (and chrome implementation) in a better shape. As such we would appreciate if you could take another look at this. Hopefully it is a lot clearer now what access this will give, and how we're thinking about doing this safely. As such would it make sense to re-open this?

[martinthomson]

Happy to reopen this if you think that it is done. The README on the repo suggests that the spec is "very early" though. But my initial assessment is that the protections described in the spec are inadequate and I am of the opinion that this should be marked harmful.

From my original comment:

For instance, if it were possible to access arbitrary directories or files, that would be very bad. It is also possibly bad if access were granted to spaces that are shared between origins or shared with native applications.

The first is only partially curtailed by allowing user agents to block access to /etc and similar, with additional discussion about ~/Downloads. The second seems not to have been addressed at all. The spec does note that this could be used for tracking, which doesn't really cover the full extent of granting multiple origins access to the same file(s).

That is relatively minor in relation to the other concern:

Working out what is safe, building systems to constrain use to fit within those bounds, and establishing norms around use are all problems that likely require significant research. We don't have any established wisdom on these topics, so I expect that will take time.

There is more substance to the current proposal, which is good, but it still falls short in this regard. I recognize the difficulty posed by trying to bootstrap this process, but - at least for me - I would like to see a lot more before I would be comfortable with this being shipped.

These concerns do not apply to getOriginPrivateDirectory, which avoids many of these issues. Though there are some minor UX concerns even there (is this folder from example.com or example.com as framed by foo.example? and how do you even communicate that distinction) getOriginPrivateDirectory is far less problematic overall.

[annevk]

(Filed WICG/file-system-access#211 on the name of that method. It does seem to use the new underlying primitive which will eventually enable proper partitioning.)

[mkruisselbrink]

The README on the repo suggests that the spec is "very early" though.

Oops, sorry about that. I forgot to update the README.

It is also possibly bad if access were granted to spaces that are shared between origins or shared with native applications.

(I assume you're talking about write access specifically, since browsers already grant read access to spaces like that) Given that that is literally the exact use case we want to enable with this API, yeah, if you consider that bad you probably won't like the API. We think that the UI affordances (permission prompts, etc) we have implemented sufficiently help the user understand what is going on, and give them enough control for this to be safe.