> The primary entry point for this API is a file picker, which ensures that the user is always in full control over what files and directories a website has access to. Every access to a user selected file (either reading or writing) is done through an asynchronous API, allowing the browser to potentially include additional prompting and/or permission checks.
I'm glad they are taking a security-focused approach from the beginning of the design phase. I expect no less from Google. However, I worry that the approach of putting the end user in charge of approving/denying access to resources puts an unreasonably high burden on users. Many people simply click to dismiss dialogs without even reading them, let alone thinking carefully about what they are agreeing to. This is asking for trouble. I would rather see a sandbox approach that restricts the locations and types of files that can be read and written.
In the main case, where the user is picking a file, the API as proposed in the examples[1] doesn't seem to suggest any ability to pre-select a file in the displayed file picker. Thus, this is a "dialog" where you literally cannot just press "OK"—you have to either select something to open first, or hit "Cancel"!
On the other hand, the last example (FileSystemDirectoryHandle.getSystemDirectory) might devolve into the sort of "user presses yes before even reading" permissions system that is so troublesome today. But I feel like the kinds of directories exposed through such a mechanism would likely be fairly innocent (the proposed example being the user's set of installed fonts.)
> Not allowing websites to write to certain file types such as executables will limit the possible attack surface.
The problem with that is there is no hard distinction between a data file and an executable. Essentially every kind of file, when opened, causes code to be executed, usually significantly influenced by the content of the file.
This API is moving the security perimeter back, making it the responsibility of every local app that may open a file touched by this API — essentially every file it might open — to ensure unexpected/malicious content can’t do anything bad. That’s not going to happen. Instead, users are going to have to be “sure” not to open files via this API using sites they don’t trust. That’s pretty weak compared to what we’re generally used to today (which doesn’t seem strong enough already).
I'm glad they are taking a security-focused approach from the beginning of the design phase. I expect no less from Google. However, I worry that the approach of putting the end user in charge of approving/denying access to resources puts an unreasonably high burden on users. Many people simply click to dismiss dialogs without even reading them, let alone thinking carefully about what they are agreeing to. This is asking for trouble. I would rather see a sandbox approach that restricts the locations and types of files that can be read and written.