I do understand why browsers would want to disallow unfettered access to the entire filesystem (and present the opportunity for the user to give too much access inadvertently), but I still wonder why even something like the non-standard Filesystem API (https://developer.mozilla.org/en-US/docs/Web/API/File_and_Di...) would choose to use a virtual filesystem as the backing store as opposed to some site-specific subdirectory in the real filesystem that the browser could control and sandbox?

Is the issue just that it would widen the attack surface too much in the event of a potential bug that could compromise the browser sandbox and/or the same origin policy? Or is there more nuance that I'm missing?

There are two kinds of problems I spontaneously see, I assume there can be found more.

For one it has to be clear to the user. Is he granting one time access or repeated access? Which sites are getting the access? Is it actually the exact page I see or some code loaded from elsewhere? etc.

The other part is the sandboxing part. Sandboxing access to file systems is hard. How do you deal with symlinks, hard links, ... (maybe there is a different vulnerability allowing to create those and both techniques together lead to an dangerous exploit?) what amount of the path name etc. are available to the application (this might i.e. link the username, which might be derived from a full name, think about /home, /Users, C:\Documents and Settings\ but might be useful to show) and then, again, the related real-life user issue: not all users have all their music in a distinct folder structure, but probably mixed with other files, and oh, they want to play the files freshly put into "Downloads", too ...

Granting such access is a can of worms ...