Hacker News Reader

Comment by jarek-foksa | Hacker News Reader

Native File System API [1] is going to be the biggest game changer in 2021. So far it was little known and rarely used because of the origin trial limitations, but it will become available to everyone soon [2].

[1] https://web.dev/native-file-system/

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=853326...

View on HN

I'm sure there is a ton of design and thought put into making the native file system API safe and secure, but wow does it scare me right off the bat. Even if it has to be enabled by a user like camera or mic permissions, this can probably be used to get malware onto the machines of users that don't pay attention to permission requests or understand the implication of what they're doing.

Many friends of mine will immediately, without thought, click to allow camera, microphone, or location data as soon as the prompt shows up. I can see the native file system permission following the same process.

It'll be interesting to see how it works. I'm sure Google has put in quite a bit of effort into securing it.

I doubt most casual users would know the distinction between "native filsystem access" and what the browser does already. They'll just (wrongly, in this case) assume the browser is safe as long as they don't download and install anything, and brazenly click Yes to every prompt that shows up.

The prompt that asks user for a permission to write a local file says: "<domainName> will be able to edit <fileName> until you close all tabs for this site [Cancel] [Save changes]".

But before this prompt is even shown, user must first manually select the file with the native file picker dialog and click the "Open" button.

Therefore, giving accidental accesses to a file is not going to be as easy as with a camera or a microphone.

It looks reasonable restriction.

This is a security nightmare. It looks like major browser vendors have pushed back against it and for good reason. Even a website I absolutely trust should not be able to access my bare filesystem because I don't know if that website will get compromised, XSS'd, DNS poisoned, etc.

I understand wanting to save files with a webapp, but why not just use LocalStorage and deserialize/serialize from that? If you need persistence plug in a cloud solution like Amazon S3. That's what the web is for.

Judging by the web.dev page this seems to be pretty well done though. Permissions are only granted to a subset of files and new sessions will need to ask for permission again.

LocalStorage is okay but a user might not be aware when LocalStorage is cleared (f.ex. they might accidentally clear it when deleting cookies). Cloud Storage might not be in the user's interest in terms of privacy. You kinda have to add some export/import functionality on top in both cases.

The level of security seems to be on pair with Electron apps running inside macOS sandbox. Even if the attacker manages somehow to inject and execute a script on the client side, it will have access only to the files that user has opened with the app recently, not the entire filesystem.

This is one of those APIs that I am equal parts excited and worried for. It'll enable awesome abilities for apps, and it's going to be a whole new level of exploits and browser fingerprinting for the malicious.

Wow, this is indeed going to be a game changer for me.

Until now, I had to ask players of my game to download a webserver to be able to create new levels and test them in the browser. Not anymore!

Reply on news.ycombinator.com