A new release of Google Chrome enables Native File System API so the developers can build web apps that interact with files on the user’s local device.
How will you use it ? 🙂
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (35)
Just a thought here. The overall the file system related use-cases on the web applications can be tackled like google drive or one drive sync pattern. Something like how our files from the local machine (in google/one drive) sync with cloud in timely fashion.
Instead of user upload directly on the web app via browser, they can upload into the sync path in local machine and that will sync the files to cloud.
TiddlyWiki
Heres a diagram of Chromes new FootGun API
Yet another reason to never install Chrome. I imagine many security conscious businesses who currently use it will be having serious conversations about removing it from their networks.
Well it will eventually be in the chromium based browsers, it was already there in flags, just disabled for everyone.
nice. next is kernel access to the browser followed by access to CPU Registers.
🤣
Yeah... This seems like a huge security issue. Correct me if I'm wrong, but most web browsers run in a sandboxed environment, making malicious attacks through just a website pretty much impossible. But with this, some website can just ask for file permissions and totally just wipe all your stuff. There would be no way to know whether or not the website is trustworthy. That's just my two cents.
There are security implications but what you are talking about isn't really feasible. The website needs permission and the picker is user controlled. A website can only access files/directories selected by the user. Saving/Editing is also another user prompt(once permission is provided for a single file it remains until the tab is closed).
So in order for what you are discussing to happen a user would have to give permission and open up a directory on the site then also hit confirm every time the site tried to overwrite a file. It's not impossible but there are notable safeguards in place to prevent this.
You're right
Oh... it must observe strictly :D
I'm make a malware that accepts "file submission", but requests write permission from the careless user, and overwrites the file when the permission was granted.
🤒
It reminds me when they disabled
SharedArrayBufferbecause of the massive Meltdown/Spectre stuff. I hope something similar doesn't happen with this.I'm definitely disabling it for everything.
I didn't know
I won't, and this "feature" needs to disappear again. That's horrid.
😅
Cannot wait for an exploit to be discovered and observe how personal information is stolen via this API.... or even without exploit, people being tricked into accepting this permission and then having malicious apps taking advantage of this.
Why is this API even necessary? I understand that for Google there is an amazing appeal about getting access to your local drive, but for the end user this means that native apps will be slowly disappearing to make room for horrible slow clunky web apps that can read all your files.
For the same reason of leave horses to get heavier cars.
Or leave assembly to get slower programming languages.
It's called evolution.
Last I checked web assembly is very usesable now. E.g. Blazor(c#) for something more mature and Yew(rust) for something still being worked on.
I use only Web Apps, I replaced all the native apps with web apps and I love it!
I think it is obvious why the API is useful, productivity apps(as well as anything else that needs open and save files) on the web suffer from the friction of uploading and then downloading a file which makes for bad UX.
You can't account for every possibility but the permission management seems clear and doesn't persist. The notifications seem fairly overt as well. The fact that it is user driven too makes it hard to imagine that many/any users would not only accidentally allow permissions but then also accidentally select a sensitive file/directory. Only time will tell though.
The 'upload' issue is actually a non-issue even without the FS API. You can (on a vast majority of modern browsers) pull off a 'fake' upload in any number of ways that works just fine without hitting the remote server.
Downloads are the big issue, because the current behavior of web browsers does not allow for apps to hint the browser that links should use 'Save As' behavior (but, FWIW, downloads don’t actually need to hit the server either, you can use either a Data URI (if the file is small enough) or the Blob API to generate a 'donwload' client side).
There's at least github.com/jimmywarting/StreamSave... (or for older browsers github.com/eligrey/FileSaver.js), it actually took me longer to figure out "uploading" files locally than saving files.
I also have the same view. The example use cases given on googles web dev page doesnt seem that relevant(Online IDE, Photo/Video editors etc). Also, spec does cover the security aspect but I still feel that this could go wrong.
Maybe this is geared towards converting web apps to offline mode. But sooner or later scammers will definitely find a way to abuse it. I would surely never give this permission to any site.
Indeed, but there are advantages for PWAs especially in Android based like DEV itself
What about security ? Can user Allow or Disallow File access ?
Why did you ask? It's obvious!
Yeah it asks for permission
How does this relate to standards, is this coming to Firefox, Safari, etc?
It's part of the project Fugu, you can probably ping Thomas Steiner about it.
I'll be interested to know the answer, so far my understanding was that it was a Chrome initiative.
This article on web.dev sums up the usage and status.
Chrome 86 only for now I guess.
Yup, not surprised about this for now, but anybody have an idea of where this might fit into the broader browser plans? I've seen this talked about, but only in the Chrome context.
I would expect no sane browser manufacturer to follow suit. Right now I can envision thousands of security admins having a complete meltdown over this and scrambling to remove Chrome from their networks ASAP. In a business environment this 'feature' is toxic.