Came here to say this too. Principle of least privilege doesn't exist here, even with the browser prompting for access to files, people are going to make mistakes and upload their entire C: directory by accident. Reminds me of Kazaa where you could essentially browse the contents of a person's hard-drive because they configured the wrong folder.
This API can allow applications that work with files to be made as strongly-sandboxed web apps instead of unsandboxed applications. If the API didn't exist and the user had to download an unsandboxed application to work with a file, then the unsandboxed application will get access to their whole C: drive without the user needing to make any mistakes.
This API can allow applications that work with files to be made as strongly-sandboxed web apps instead of unsandboxed applications
That's possible today using the browser's existing file-handling APIs. As the author points out, there is a hurdle—and possible annoyance—from the user's perspective, which is that rather than pressing Cmd+S (or whathaveyou) and having that silently "just work" (i.e. as it does any any traditional desktop app), the user is kept in the loop during the entire process, from placement (i.e. which directory to save the file to), to having to explicitly grant the ability to overwrite the existing file if one already exists with that name.* Despite the fact that it's possible, however, few application authors have taken advantage of the opportunity. I don't expect this to change much with file access APIs.
The truth of the matter is that the majority of contemporary web app authors like having the opportunity of being the gatekeepers for the user's data—even when the other party 99% of the time is the user themselves.
What's most likely to happen is that similar numbers of web app authors continue not to use these APIs as we see today, partly because the API is too complicated. Where we will see it used will be instances where the net effect to the user is further loss of control over their data.
I'd be in favor of a drastically simplified API that was narrowly created to address the ergonomics issues of the file overwrite problem, and to encourage browser makers to limit further file access API expansion to applications that are themselves accessed with the `file` URI scheme. That is, rather than navigating to hosted web app and granting it permissions for file access, in addition to saving your data to your local disk, you're given a static copy of the web app, too. You're able to open this from disk and it is this copy to which you are allowed to grant file access permissions. If it's true that developers really do care about these file access APIs for the purpose of enabling users to exercise greater control over their data, then they should have no issue making this concession as a show of good faith.
* A simple workaround to this is to not try to overwrite the original, but instead save a new file that sits beside the old one. The application author can help out here by automatically generating a "tag" included in the suggested file name, so when the system filepicker is called up, the user just presses Enter and is never bothered with the overwrite prompt. Many people end up creating their own ad hoc versioning schemes ("final final final") at some point, anyway, so this constraint—which is on the surface considered more onerous than the status quo for typical desktop apps—can actually lead to a workaround that is much nicer to work with than the status quo. (Food for thought: if we reached a stable equilibrium concerning the conventions on this, OS vendors could bake awareness in somewhere just above the filesystem level and kill of "final final final" completely—and expose all sorts of useful services that would not otherwise be possible with the ad hoc schemes.)
The spec explicitly allows for browsers to reject paths which are too sensitive or dangerous, even if the user selects it. They explicitly list the entire Downloads directory as one such example (while also saying individual files from said directory are ok).
Comments
Came here to say this too. Principle of least privilege doesn't exist here, even with the browser prompting for access to files, people are going to make mistakes and upload their entire C: directory by accident. Reminds me of Kazaa where you could essentially browse the contents of a person's hard-drive because they configured the wrong folder.
This API can allow applications that work with files to be made as strongly-sandboxed web apps instead of unsandboxed applications. If the API didn't exist and the user had to download an unsandboxed application to work with a file, then the unsandboxed application will get access to their whole C: drive without the user needing to make any mistakes.
That's possible today using the browser's existing file-handling APIs. As the author points out, there is a hurdle—and possible annoyance—from the user's perspective, which is that rather than pressing Cmd+S (or whathaveyou) and having that silently "just work" (i.e. as it does any any traditional desktop app), the user is kept in the loop during the entire process, from placement (i.e. which directory to save the file to), to having to explicitly grant the ability to overwrite the existing file if one already exists with that name.* Despite the fact that it's possible, however, few application authors have taken advantage of the opportunity. I don't expect this to change much with file access APIs.
The truth of the matter is that the majority of contemporary web app authors like having the opportunity of being the gatekeepers for the user's data—even when the other party 99% of the time is the user themselves.
What's most likely to happen is that similar numbers of web app authors continue not to use these APIs as we see today, partly because the API is too complicated. Where we will see it used will be instances where the net effect to the user is further loss of control over their data.
I'd be in favor of a drastically simplified API that was narrowly created to address the ergonomics issues of the file overwrite problem, and to encourage browser makers to limit further file access API expansion to applications that are themselves accessed with the `file` URI scheme. That is, rather than navigating to hosted web app and granting it permissions for file access, in addition to saving your data to your local disk, you're given a static copy of the web app, too. You're able to open this from disk and it is this copy to which you are allowed to grant file access permissions. If it's true that developers really do care about these file access APIs for the purpose of enabling users to exercise greater control over their data, then they should have no issue making this concession as a show of good faith.
* A simple workaround to this is to not try to overwrite the original, but instead save a new file that sits beside the old one. The application author can help out here by automatically generating a "tag" included in the suggested file name, so when the system filepicker is called up, the user just presses Enter and is never bothered with the overwrite prompt. Many people end up creating their own ad hoc versioning schemes ("final final final") at some point, anyway, so this constraint—which is on the surface considered more onerous than the status quo for typical desktop apps—can actually lead to a workaround that is much nicer to work with than the status quo. (Food for thought: if we reached a stable equilibrium concerning the conventions on this, OS vendors could bake awareness in somewhere just above the filesystem level and kill of "final final final" completely—and expose all sorts of useful services that would not otherwise be possible with the ad hoc schemes.)
The spec explicitly allows for browsers to reject paths which are too sensitive or dangerous, even if the user selects it. They explicitly list the entire Downloads directory as one such example (while also saying individual files from said directory are ok).
It’s not possible to grant access to C: