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).

[ylafon]

Closing this as there is nothing problematic here, however it would have been nice to have an answer about returning an uuid-urn instead of just an uuid that matches your need, as you use this as an identifier.
Cheers,

[a-sully]

Hi all, apologies for the lack of response. I just realized I had accidentally been filtering emails related to this repo. facepalm

@ylafon you're correct that I've (perhaps naively) proposed using a uuid because that's what matches my use case (i.e. an identifier for a file which is unique per site and persistent until site data is cleared). I'm not too familiar with the range of other options available - what would be the advantage of making this a uuid-urn?

See some previous discussions about ID/URL for more context: whatwg/fs#46 (comment)