#773: FileSystemHandle.remove() for the File System Access API

Visit on Github.

Opened Sep 9, 2022

Wotcher TAG!

I'm requesting a TAG review of FileSystemHandle::remove() for the File System Access API.

Currently, it is not possible to remove a file or directory given its handle. You must obtain the handle of the parent directory, which there is no straightforward way to do and may not be possible in some cases, and call FileSystemDirectoryHandle::removeEntry().

Introducing a new method, FileSystemHandle::remove() (which follows the pattern of https://dom.spec.whatwg.org/#dom-childnode-remove), enables the common use case where you obtain a file handle from showSaveFilePicker(), but then decide you don't want to save after all, and delete the file.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the work on this specification is currently being done: whatwg/fs (initial work was started WICG, but the relevant parts to this proposal have been moved to whatwg)
  • The group where standardization of this work is intended to be done: whatwg/fs
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2022-10-10

Minutes

bump to plenary

2022-10-17

Minutes

punt until we can discuss with Tess

2022-11-14

Minutes

Amy: looked through the security & privacy responses - no red flags so far but a bit more work to do.

2022-11-28

Minutes

Amy: seems like a small thing... seems reasonable. Related but differrent to the previous one. Not much in the way of multi-stakeholder.

Peter: I'm concerned - in the explainer - what happens if you get a file handle from open file and decide to delete ...

Sangwhan: shouldn't that throw?

Peter: the explainer is a PR... Not exactly the best way to review.

Amy: the Security & Privacy doc just goes to the general S&P doc for the overall spec - not specific to this change.

Dan: should we force them to do some work?

Peter: I kind of think so. It does reject unless you have read-write permission.

Sangwhan: we should ask the question.

Peter: allows recursive directory removal... could be dangerous. Let the user pick a random system or home dir and recursively delete everything in one call

Sangwhan: yeah i guess if the user does something .. I think the root dir is disallowed... There's a platform-specific list of things you can't do...

Peter: a lot of damage you can do below root

Sangwhan: list of things you can't do are very platform-specific

Amy: [will draft comment]

Thanks for your review request. On the surface, the developer need you have laid out seems reasonable. Could you articulate this in terms of the impact on the end user, in a small standalone explainer please? Also it would be helpful if you can respond to the security & privacy questionnaire in a way specific to this addition to the spec. We would like clarity on cases where the file handle is obtained from an open file (as opposed to from `showSaveFilePicker()`), as well as mitigations against the risks of recursive directory removal using this method.
2022-12-19

Minutes

Dan: there's an explainer now...

Amy: I left a comment with concerns ... I don't think they've addressed that. Also no security & privacy ... There's a security considerations and mentioned recursive directory removal is "already possible" .. I want to believe they've thought about the footgun implications of this. Overall it's probably fine.

Dan: there's a gecko positive link, but it's just to a comment from Anne not an actual standards position

Amy: Does seem like it might be problematic if it's inconsistently implemented between browsers though

Dan: will ask if there's a mozilla standards position

Amy: their "developer: positive" is an issue with 3 comments on it.

Amy: in the explainer they haven't really expressed it in terms of user needs. But it's a bigger concern if only one browser implements this, as developers will need to right multiple code paths anyway, so it doesn't solve the problem they are trying to solve

Amy: we need feedback from Sangwhan, Lea...

Bring to plenary

2023-02-13

Minutes

Amy: the material at the end of the explainer link is not an explainer from the user needs perspective.

Dan: yes - no separate explainer and no user needs stated.

Amy: it's from the site's perspective - i don't think the "site" can be said to want anything.

Sangwhan: it shipped in 110 - last month.

Amy: says "positive signals" from firefox and the the comment was not clearly positive. Positive signals from developers was also less than clear. In my comment I had 2 questions and I don't think they've been answered in the explainer. No mitigations against the risk of recursive directory removal specified...

Dan: should we say "we're concerned - you've shipped but not engaged with our feedback"

Amy: I can leave a comment...

Sangwhan: I think we should put it to resolution timed out...

Dan: suggest we close the issue - amy to leave comment, sangwhan to close issue.

consensus reached to close
2023-03-06

Minutes

Amy: will write closing comment.

Hi there. We discussed this in our call a couple of weeks ago. We understand that this has already shipped so there probably isn't any more feedback we can usefully give here. We remain concerned about the multi-stakeholder engagement, and what happens if support for this is inconsistent between UAs. We also don't see an answer in the explainer to the questions I left in December, or information in the explainer about the impact this proposal has from a web user's perspective (rather than a site author).