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.
SEE: Cross-site scripting attacks: A cheat sheet (TechRepublic)
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 Writable Files API still at the design stage, it will still be some time before it is implemented in browsers, with Google warning that not all of the ideas developed by the WICG will make it to release.
- Changes to Google Chrome and Chrome OS certificate handling (TechRepublic)
- How to set site-by-site permissions in Google Chrome (TechRepublic)
- How to clear corrupt Google Chrome sync data (TechRepublic)
- How to use Chrome's built-in anti-malware tool (TechRepublic)
- Windows support scam uses evil cursor attack to hijack Google Chrome sessions (ZDNet)
- Chrome 70 released with revamped Google account login system (ZDNet)
Nick Heath is chief reporter for TechRepublic. He writes about the technology that IT decision makers need to know about, and the latest happenings in the European tech scene.