idea - allow websites default directory access to $HOME/Downloads/<domain.name>

[kaizhu256]

in example of https://googlechromelabs.github.io/text-editor/, file-api could allow default read/write access to ~/Downloads/googlechromelabs.github.io/ which is isolated from other sites.

pros:

• websites have access to isolated directory in ~/Downloads/ w/o needing user-prompt

cons:

• how to handle in headless-browser?
• what about operating-systems lacking a ~/Downloads/ directory?
• how to handle localhost (and different ports)?
• what if there already exists directory ~/Downloads/googlechromelabs.github.io/ arbitrarily created by user with sensitive data (need some way to check if created by file-api and if not then prompt user)?

[Anoesj]

This doesn't seem like a good idea to me. It would grant websites permission to download all kinds of stuff to your computer, such as malicious .exe file. Technologically illiterate people may open such files without knowing the risks.

[barhemo]

I agree with this idea.

[jimmywarting]

I do think the sandboxed navigator.storage.getDirectory() is sufficient for a private origin storage without prompts. Can be good that it's clearable too sometimes by the browser.
if the case is that you want it to be located in a user specific folder for permanent use and be safe against data removal when browser has to tidy up, then #238 is the issue to tackle to reduce the burden of having to re-prompt for read/write access again and again

[yume-chan]

in example of https://googlechromelabs.github.io/text-editor/, file-api could allow default read/write access to ~/Downloads/googlechromelabs.github.io/ which is isolated from other sites.

It's still unclear to me that why this website want to access the downloads folder, and how it will use it.

In my opinion, the most common usage for an isolated download folder is to download (multiple) large dynamicly generated files like what StreamSaver.js does now.

to download all kinds of stuff to your computer, such as malicious .exe file.

An a[download] is enough for that.

w/o needing user-prompt

I think a prompt is still required, like nowadays Chrome has the "download multiple file" ("Automatic downloads") permission. But compare to showDirectoryPicker() with starting directory, this method:

1. Is easier for users to understand that, the website want to download files, instead of a randomly opened directory picker, or relying on website design to teach the user.
2. Doesn't need to save a handle in IndexedDB, and never need re-prompt, which simplify development.

---

Considering Security Considerations -> Websites trying to use this API for tracking (https://wicg.github.io/file-system-access/#privacy-tracking), this handle should only have write access (#119), that's enough for my "most common usage".

---

EDIT: It's even possible for browsers to integrate existing file downloading logic with operations on this special file handle, including showing download progress or history, automatically rename files when exists, etc.

---

EDIT2: What I want is more like #29

[a-sully]

Closing this issue since the original request ("default directory access to $HOME/Downloads/<domain.name>") is not something we plan to support. As mentioned above (#235 (comment)), the OPFS is our recommended solution for an site-isolated file system without any prompts

@yume-chan I've been kicking around some ideas for how we can improve this API for download-like use cases, but it's not on our roadmap in the near future. I expect those discussions to happen on #29 and #119, so subscribe to those issues and stay tuned :)

[a-sully]

Oh also, more persistent access to files outside outside of the OPFS is coming soon. I hope to post an update to #297 in the coming weeks