#764: FileSystemHandle Unique ID

Visit on Github.

Opened Aug 12, 2022

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.

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

Discussions

Discussed Oct 10, 2022 (See Github)

Yves: I looked at this a bit - they want to hide info about the file... I wonder why they are not generating URN IDs for that... what they described is a URL resolver of some kind... I will propose that even though URNs are not the best...

Yves: they are hiding things with UIDs for local files ... probably a good thing - from a pov of obfuscating... based on time for example you might not get the same UID... also they want that to be keyed with the web site as well... You cannot infer from the UID what files you're working on...

yves to leave comment

Comment by @ylafon Oct 12, 2022 (See Github)

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

Discussed Oct 17, 2022 (See Github)

Amy: is this releated to the other FileSystemHandle issues?

Yves: sent a comment saying it looks like UUID-URNs and didn't hear back. It's different from the other issues.

Discussed Oct 24, 2022 (See Github)

Yves: still pending feedback. Bump by two weeks as I won't be here next week.

Hadley: do we need to nudge them?

Yves: I don't think so, I can look at other places where it might be discussed

[bump +2 weeks]

Discussed Nov 14, 2022 (See Github)

Yves: no response to my question but apart from that it seems reasonable. So suggest we close.

Dan: happy to close on that basis.

Comment by @ylafon Nov 16, 2022 (See Github)

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,

Comment by @a-sully Mar 16, 2023 (See Github)

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: https://github.com/whatwg/fs/pull/46#issuecomment-1217341995