FileSystemHandle Unique ID

[a-sully]

Wotcher TAG!

I'm requesting a TAG review of FileSystemHandle Unique ID for the File System Access API.

Currently, FileSystemHandle objects can be opaquely serialized by the browser to be stored as values in IndexedDB. But there is no way for a site to generate a string from script which is guaranteed to be uniquely identifying for the file referenced by the FileSystemHandle. Several developers have requested this.

In the proposal, FileSystemHandles vend string IDs. The IDs uniquely identify the file that is referenced, but their validity is tied to the site and storage to maintain privacy guarantees.

• Explainer: whatwg/fs/pull/46
• User research:
• Security and Privacy self-review²: WICG/file-system-access/pull/383/
• GitHub repo: 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/5190893263388672

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): whatwg
• The group where standardization of this work is intended to be done ("unknown" if not known): whatwg
• Existing major pieces of multi-stakeholder review or discussion of this design: whatwg/fs/pull/46. This is still an early proposal and we haven’t received feedback yet
• Major unresolved issues with or opposition to this design:
• This work is being funded by: Google

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

[ylafon]

It really looks like minting a resolver that could be an uuid-urn resolver.
Have you thought about that string being an URL? (Well, URN in that case, but you have a resolver, so it is almost an URL).