[streptomycin]

This isn't new, the API has been around for several years. Unfortunately Mozilla and Apple say they are never going to implement it because of security concerns https://github.com/mozilla/standards-positions/issues/154

It is a great API though, I wish the other browser vendors liked it! Because currently us PWA developers are really limited when trying to make apps that work with local data, at least in non-Chrome browsers.

[sharperguy]

You could implement it this way:

- the first time you select a directory it must be empty

- you can drag files in there afterwards

- the directory gets whitelisted for future use

Probably has bad usability, but would be more secure.

[codedokode]

Firefox position is completely valid. I think a safe option would be to allow access only to a specific directory like "~/Internet files" or something like this. This way the user could grant the access but not to sensitive files. And add an option in about:config to lift the restriction for power users.

Also, there is a risk of a site writing malware executable, and Linux currently has no sandboxing for such executables so the system would be completely owned once the user runs the program. So the directory should not allow storing executables.

[benregenspan]

I'd love for Google to figure out something comparable for the Drive API (currently it's not possible to grant read/write access to a single folder; you need to grant access to the entire drive!): https://issuetracker.google.com/issues/36760598?pli=1

I think the fact that the above issue has been open for a very long time is one indication of how difficult and sensitive this type of access control API is. The Google Drive API could be a proving ground for getting the UX right for this (including tricky details like how to manage persistent access to a folder with clear disclosure and user controls).

[ethbr1]

Is it really that complicated?

Why not just create per-domain browser-controlled folders (cert-linked?) that are abstracted into a simple read/write API via the browser (with subfolders allowed under that domain's root), disallow cross-domain access... and then build browser-mediated linking for use cases where you want to flow files from (non-domain) to (domain) to (non-domain)?

So essentially local storage with better integration with the actual filesystem, that's browser-controlled.

Allowing websites to have arbitrary (even user-approved) access directly to the real filesystem seems like a bad idea, when most use cases could be handled by a browser-mediated filesystem-like abstract view.

[NooneAtAll3]

fortunately*