Live data from Hacker News

Web Writable Files API: Simplifying Local File Access

developers.google.com

41–50 of 115 posts

Re: Web Writable Files API: Simplifying Local File Access

#41
post #30

One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine. 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. How easy would it be to trick my mother into uploading her profile picture and have the site change that file into…

As you surely noticed, for last 10 years the browser is actively trying to replace your desktop OS, so that the browser would become the platform, instead of Windows / macOS / Linux / anything else. Imagine the desktop becoming ChromeOS on any computer, not just Chromebooks. For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, p…

The ChromeOS browser does not have access to local files, it can download files to a ~/Downloads folder, but it cannot manipulate local files.

The entire point of ChromeOS is aggressive sandboxing, not breaking out of the sandbox.

Re: Web Writable Files API: Simplifying Local File Access

#42
A couple months ago I started studying PWA.

I realized PWA's potential was on Desktop and not really on mobile.

I came to realize that PWA missed really two things to change Desktop for good :

- Sandboxed FileSystem API

- Standard Operating System Support

Most apps like Slack, Discord or Twitch can barely justify their usage of Electron... beside the possibility to have those apps in a separate OS Window they don't make an extensive usage of Node.JS like VSCode which spawn "child_process".

They just seat there , in a separate OS Window and they can launch at OS startup too..but in order to have those two features you must completely give up on security and give access to almost everything on your computer...

PWA really bring a new dimension to Desktop App, if Windows and MacOS brought native support to PWA ( using Edge and Safari without the need for Chrome ) this would change the industry for ever.

Re: Web Writable Files API: Simplifying Local File Access

#43

Is this API needed? I understand the benefits, but web apps or Chrome extensions that _really_ need file access can already use the Native Messaging API and ask the user to install a native app, like here: https://a9t9.com/kantu/x#fileaccess The advantage of an explicit app installation is that users/companies that want to avoid such file access (and the many other things that native apps can do) can simply avoid/blo…

I don't know that native apps are the best resolution, but I absolutely agree with the last paragraph. There needs to be really clear user messaging around this type of access. The current state is, IMO, insufficient.

Re: Web Writable Files API: Simplifying Local File Access

#44
post #30

Earlier quoted context omitted.

As you surely noticed, for last 10 years the browser is actively trying to replace your desktop OS, so that the browser would become the platform, instead of Windows / macOS / Linux / anything else. Imagine the desktop becoming ChromeOS on any computer, not just Chromebooks. For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, p…

The ChromeOS browser does not have access to local files, it can download files to a ~/Downloads folder, but it cannot manipulate local files. The entire point of ChromeOS is aggressive sandboxing, not breaking out of the sandbox.

Apparently I can write files in ChromeOS.

https://developer.chrome.com/apps/fileSystem

Re: Web Writable Files API: Simplifying Local File Access

#45

This is a great idea and will mean that many Electron applications can just run much more securely as plain web applications.

I don't have any issues with PWA apps, actually quite like the idea, specially how it is done on Windows, ChromeOS and Android.

Electron ones is another matter, I already have enough browsers installed.

Re: Web Writable Files API: Simplifying Local File Access

#48

This is a great idea and will mean that many Electron applications can just run much more securely as plain web applications.

Relying upon browser features for native access will be trouble. Google could revoke the feature from chromium at any time. And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata.

> And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata.

I think a lot of what you'd store in Appdata in a "real" application will remain in browser storage or pulled from the server. A single file or folder with app settings, drafts, etc. should suffice. And even settings are probably better stored server side for user convenience so they can easily switch devices.

Re: Web Writable Files API: Simplifying Local File Access

#49
post #44

Earlier quoted context omitted.

The ChromeOS browser does not have access to local files, it can download files to a ~/Downloads folder, but it cannot manipulate local files. The entire point of ChromeOS is aggressive sandboxing, not breaking out of the sandbox.

Apparently I can write files in ChromeOS. https://developer.chrome.com/apps/fileSystem

You get access to this if you have written a Chromebook app. If you get a user to install that, there is a clear set of permissions they are accepting. See the section on permissions, which is specified in the app manifest. It is not an open hole for anything running on a Chromebook.

Re: Web Writable Files API: Simplifying Local File Access

#50
post #31

One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine. 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. How easy would it be to trick my mother into uploading her profile picture and have the site change that file into…

And more than that, I honestly wonder about the motives of an advertising driven company these days. It feels like 5 years later this will come to bite us in the ass as another way of exploiting access to our computer and data. What if websites start requiring specific files to exist before allowing access?

> What if websites start requiring specific files to exist before allowing access?

This is certainly going to be immediately abused for encrypted storage of persistent cookies and tracking identifiers.

- If my site generates cat pics, I'll put identifiers in the metadata fields of the image format.

- If my site generates markdown, I'll put identifiers in an alternate data stream (Windows) or encoded in the whitespace.

Since the files exist outside of the sandbox, they'll be outside of the scope of privacy features like clearing the cache or cookies, and outside of the reach of adblocker extensions.

Post reply on HN