[w3ctag/design-reviews] The `FileSystemObserver` interface (Issue #868)

こんにちは TAG-さん!

I'm requesting a TAG review of the `FileSystemObserver` interface for the [File System specification](https://fs.spec.whatwg.org/).

This proposal introduces a `FileSystemObserver` interface which will much more easily allow a website to be notified of changes to the file system.

The file system is a shared resource that can be modified from several contexts. A [Bucket File System](https://fs.spec.whatwg.org/#sandboxed-filesystem) (a.k.a. an [Origin Private File System](https://github.com/whatwg/fs/commit/69c51d387cc94e86c8a26acbc0051d7c2a560cfd), or OPFS) spans numerous [agents](https://tc39.es/ecma262/#sec-agents) - tabs, workers, etc - within the same [storage key](https://storage.spec.whatwg.org/#storage-keys). The local file system also spans across origins and other applications on the host operating system.

Currently, for a given agent to know about modifications to the file system - made either by itself or from some external context - it must poll the file system to detect changes. This is inefficient and does not scale well.

  - Explainer: https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md 
  - Security and Privacy self-review: No changes to [the existing review](https://github.com/WICG/file-system-access/blob/main/security-privacy-questionnaire.md), though that review [needs to be updated](https://github.com/WICG/file-system-access/issues/421) to consider interaction with pages which are not [fully active](https://html.spec.whatwg.org/multipage/document-sequences.html#fully-active). In the meantime, this feature’s interaction with non-fully-active pages is discussed [here](https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md#handling-changes-made-outside-the-lifetime-of-a-filesystemobserver). See also the [Permissions Considerations](https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md#permission-considerations) and [Fingerprinting Risk](https://github.com/whatwg/fs/blob/main/proposals/FileSystemObserver.md#fingerprinting-risk) sections of the explainer
  - GitHub repo: [whatwg/fs](https://github.com/whatwg/fs/)
  - Primary contacts (and their relationship to the specification):
      - Austin Sullivan (@a-sully), Google Chrome
  - Organization/project driving the design: Google/Chromium
  - External status/issue trackers for this feature: https://chromestatus.com/feature/4622243656630272

Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - The group where the incubation/design work on this is being done: [whatwg/fs](https://github.com/whatwg/fs/) and [WICG/file-system-access](https://github.com/WICG/file-system-access)
  - The group where standardization of this work is intended to be done: [whatwg/fs](https://github.com/whatwg/fs/)
  - Existing major pieces of multi-stakeholder review or discussion of this design: Developers have enumerated several use cases, discussed various designs, and provided example code for how file paths can be watched with the existing APIs in https://github.com/WICG/file-system-access/issues/72. No discussion with other stakeholders yet
  - Major unresolved issues with or opposition to this design:
  - This work is being funded by: Google

You should also know that...

The proposed interface can be used to observe both files on the user's local device (as specified in [WICG/file-system-access](https://github.com/wicg/file-system-access/)) and files in the Bucket File System (as specified in [whatwg/fs](https://github.com/whatwg/fs/)).

We'd prefer the TAG provide feedback as (please delete all but the desired option):

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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/868
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/868@github.com>