The security implications of writable files would depend on how long access to files is granted for:
-
If it is only for the session, it may only be a minor problem. There would be the issue of web applications prompting the user to open a file and then modifying it without permission. This could happen even if the browser warns the user that she is granting write access, as users don’t always read warnings or know whether they present a security issue. Granting access only for a session would make it difficult to implement features such as automatically opening recent files.
-
If it is persistent, as would be required for functionality such as recent files, it may be more serious. A user might open a file with a webapp, granting it write access, and then the webapp modify it six months down the line, with the user having no way of knowing that the webapp modified it. They could use a browser UI to check which origins have access to which files, but this is unlikely to be something that non-technical users would do.
“Web applications having writable access to files for an extended period of time presents a security problem. This proposal avoids this by giving the user agent control over the process based on user interaction.”
The user agent already has control of everything. Also, what is the security problem? The user would have already given permission to write to the opened file, and the browser could allow selecting whether access is retained.
It would have control in the sense that it would determine when files are opened or saved, rather than the web application determining this. The security issues would be:
- A web application asks the user to select a file to open, but actually writes to it, either immediately, or at a much later date if it retains access. Even if the browser makes clear that the user is granting write permission, the user may not take note of this if they don’t read warnings.
- A web application asks the user to download a file, but retains access to it and overwrites it at a later date. As above, the web application may warn of the risk but it is likely to be difficult for the browser to convey this risk in a way the user can understand, and it would be difficult for the user to determine whether the webapp really needs what it is asking for.
“This would tackle the issue of sites billing “save as” like “download,” as it would be clear to the user that the user agent is saving the app’s represented file rather than downloading something.”
How is that a meaningful difference to users?
“Download” is an action that writes to a file on a one-off basis, while “save as” would allow a webapp to retain access to a file.
“In native applications, a lot of boilerplate code has to be written for applications to be able to open, save, etc. This proposal would make it a much simpler process for web applications.
It would save webapps from writing a lot of boilerplate code for opening and saving files and keeping track of open files.”
Actually, that api looks rather unnecessarily complicated, compared to the open/save simplicity of the writable files proposal or even the more powerful native chrome.fileSystem api.
Fair enough. It requires less code to work with files but has the tradeoff of being conceptually harder to learn to use. There may be a way to better explain how the API works.
How would integration with other apis be simpler?
The example I have in mind is if an API is created for cloud file managers such as Dropbox to open files:
- With the writable files API, there may be no way for the user agent to know which filetypes a webapp is capable of handling, or to open a file with a webapp programmatically. If such an API was part of writable files, there would be no incentive for webapps to implement it initially as user agents would not be using it yet.
- With a represented files API, the user agent would already have a list of webapps supporting opening and/or saving a particular filetype, and a way to programmatically open them with a particular webapp.
The browser would also have the flexibility to e.g. replace saving changes to text files with committing to a git repo. Whereas a writable files API would require webapps to be quite rigid in their UI and expectations around opening and saving, a represented files API would make it possible to replace the UI around saving with UI to commit changes and write a commit message.
For example, when I open a code editor, I want it to automatically open whatever files I had previously.
This would be something that the user agent (or an extension) could implement for all apps. If it is more appropriate for some apps than others it may be helpful for them to be able to hint at the behaviour most suited to them.
