#764: FileSystemHandle Unique ID
Discussions
2022-10-10
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
2022-10-17
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.
2022-10-24
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]
2022-11-14
Yves: no response to my question but apart from that it seems reasonable. So suggest we close.
Dan: happy to close on that basis.
OpenedAug 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 theFileSystemHandle
. 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:
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