Google has taken another step towards letting web apps in Chrome edit and gather information about your files.
Using the new Native File System API, web apps would be able to read and save files, as well as gather info on the number and names of files stored on your device.
To offset the risks, Google says it is putting in place controls that would only allow the feature to be used on “secure” sites and web apps, and only with express user consent.
Google developer advocate Pete Le Page detailed how the API is available to test locally in Chrome 77, hidden behind a developer flag, and will be available for more widespread testing by developers in the forthcoming Chrome 78.
Google and its fellow browser makers have been frank about the risks of the feature, previously known as the Writeable Files API, which they spell out in an explainer page.
“By far the hardest part for this API is of course going to be the security model to use,” they write.
“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.”
Those risks are too great for some users, who are concerned the feature will break down an important wall that exists between the web browser and a user’s computer.
SEE: The Dark Web: A guide for business professionals (free PDF) (TechRepublic)
“One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine,” wrote one browser user.
“Features like this chip away at that trust model and open up new attack vectors against unsuspecting users. I get the usability benefits, but the security implications are scary.”
Google’s Le Page devotes much of his post to the security measures aimed at stopping the feature from being abused in Chrome.
“A web app cannot modify a file on disk without getting explicit permission from the user,” says Le Page.
Only sites and web apps that are opened in a secure context, delivered over an authenticated and encrypted channel, will be able to use the feature.
Files will be opened using a file picker, where the user has to select the files they want to grant access to and the user will be able to cancel access at any time. Similar restrictions apply when saving a file, with the user having control over the name and location of the saved file via a file picker. Where multiple files are to be edited, the user may be prompted to give permission at the time of opening those files.
Le Page says the browser “may limit the user’s ability to save to certain folders, for example, core operating system folders like Windows, the macOS Library folders, etc”, and in those instances may show users a prompt and ask them to pick a different folder.
When the user has given access to a web app to edit files, the icon below will appear in Chrome’s Omnibox. Clicking on the icon lists the files the browser has access to, with the user able to revoke access.
Web apps will only have access to files for as long as the browser tab is open, although, in future releases of Chrome, Google is planning to allow installed Progressive Web Apps to be granted persistent access to files, by saving file handles to IndexedDB databases.
This breaking down of barriers between the web and the device is unsurprising given the continued evolution of the browser from a website portal to a cross-device platform for running apps, with WebAssembly promising to make it possible for the browser to run even particularly demanding apps.