A group led by Google and Mozilla is working to make it easy to edit files using browser-based web apps but wants advice on how to guard against the "major" security and privacy risks.
The idea is to allow users to save changes they've made using web apps, without the hassle of having to download new files after each edit, as is necessary today.
"Today, if a user wants to edit a local file in a web app, the web app needs to ask the user to open the file," said Google developer advocate Pete LePage.
"Then, after editing the file, the only way to save changes is by downloading the file to the Downloads folder, or having to replace the original file by navigating the directory structure to find the original folder and file. This user experience leaves a lot to be desired, and makes it hard to build web apps that access user files."
SEE: Mobile app development policy (Tech Pro Research)
To this end, the W3C Web Incubator Community Group (WICG), which is chaired by representatives from Chrome developer Google and Firefox developer Mozilla, is working on developing the new Writable Files API, which would allow web apps running in the browser to open a file, edit it, and save the changes back to the same file.
However, the group says the biggest challenge will be guarding against malicious sites seeking to abuse persistent access to files on a user's system.
"By far the hardest part for this API is of course going to be the security model to use," warns the WICG's explainer page for the API.
"The API provides a lot of scary power to websites that could be abused in many terrible ways.
"There are both major privacy risks (websites getting access to private data they weren't supposed to have access to) as well as security risks (websites modifying executables, installing viruses, encrypting the users data and demanding ransoms, etc). So great care will have to be taken to limit how much damage a website can do, and make sure a user understands what they are giving a website access to."
The guide also warns that persistent file access allowed by the API could also be used as a form of "super-cookie", although this access should be revoked when cookies/storage is cleared.
Google stresses that the "primary entry point" for the API would be a file picker, so the user would still have control over which files and directories a website had access to.
The use cases for the API says it should allow web sites and apps to read, edit, save, auto-save, create and delete local files on a user's device, as well as to read meta-data about files. It is designed to be a modernized version of a variety of existing browser-based APIs for accessing files, such as the existing Entry and FileWriter APIs.
The WICG is currently gathering feedback and designing the API, and Google is asking for advice on how the permissions model for the API should work and what restrictions should be placed on it, via this page.
With the WritableFiles API still at the design stage, it will still be some time before it is implemented in browsers, with Google warning some that not all of the ideas developed by the WICG will make it to release.
Automatically sign up for TechRepublic's Best of the Week Newsletter for more hot tips and tricks. Subscribe
firedfox0 on November 23rd, 2018 at 16:03 UTC »
It's a hacker's wet dream! Even if a computer is 100% patched, beef-xss (a hacking tool that puts up a malicious website with javascript programs) is still able to slip through most firewalls, profile devices, allow for social engineering attacks and more.
Making browsers even more powerful than they already are is a bad idea.
But it would make the development cycle easier, so you know they are still going to do it.
itsfullofbugs on November 23rd, 2018 at 15:54 UTC »
"Google, Mozilla" ends up as "Godzilla" in my head.
goodeyedeer on November 23rd, 2018 at 15:03 UTC »
This is the W3C pushing for the feature, not just Google and Mozilla...