Web Writable Files API: Simplifying Local File Access
developers.google.com
Web Writable Files API: Simplifying Local File Access
1–10 of 115 posts
Re: Web Writable Files API: Simplifying Local File Access
#2This looks great! I hope a capability driven multi-monitor api gets some attention in the near future too!
Re: Web Writable Files API: Simplifying Local File Access
#3This is a great idea. One interesting consideration would be how it would handle symlinks. Would it follow them? Could that be used as an attack vector to exit the user-specified directory?
Re: Web Writable Files API: Simplifying Local File Access
#4This is a great idea. One interesting consideration would be how it would handle symlinks. Would it follow them? Could that be used as an attack vector to exit the user-specified directory?
Great!!!
Re: Web Writable Files API: Simplifying Local File Access
#5This looks great! I hope a capability driven multi-monitor api gets some attention in the near future too!
great!
Re: Web Writable Files API: Simplifying Local File Access
#6[deleted]
Re: Web Writable Files API: Simplifying Local File Access
#7[deleted]
While I'm concerned the security implications greatly, one should not always assume network access always works or that it is effective at all times. In the United States, for example, bandwidth limitations and caps are rampant far and above what is needed just to saite the greed of our corporations. Given the current political control of the judiciary and executive branches, I don't expect this to change any time soon. We'll likely see more and more limits to our ability to do "cloud" things unless we offer a greater profit than ever before to the incumbent ISPs.
Being able to do something offline is important. I can see how this goes forward with Google goal to get their "chrome is an OS" model.
Re: Web Writable Files API: Simplifying Local File Access
#8> 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.
Re: Web Writable Files API: Simplifying Local File Access
#9This is a great idea and will mean that many Electron applications can just run much more securely as plain web applications.
Re: Web Writable Files API: Simplifying Local File Access
#10> 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 t…
> I would rather see a sandbox approach that restricts the locations and types of files that can be read and written.
Which is exactly what is in the security proposal linked at the bottom of the article.