Reliance on the generic security origin specification limits the web file-handlings APIs ability to compete with traditional applications.

[kevlar700]

The security of the file-handling api seems to be tied solely to https origins. It was not designed for application use cases and is severely limiting. Especially where an application is required to work whether internet access is EVER made available or not.

A better security fit might be one or a combination of local execution(browser flag), signed files or a sufficiently long and so unguessable UUID.

To avoid PKI, there could be a PK execution flag or UUID provided upon browser execution. The security origin would then be based upon the ability to execute the browser with a special argument for access to an apps files. This access could be local only. The files could be stored by reference or even required to be signed with the Public Keys corresponding Private Key.

There is already an app execution flag.

This would make file access packages such as hive more useful. Simplify file access for applications via development unification such as for Go powered web apps and also help extend projects like flutter for web to even more platforms such as where Dart support is lacking, e.g. OpenBSD.

[fallaciousreasoning]

(NOTE: I no longer work on this, my views are my own).

To be honest, I'm a little confused by this request and it's quite possible I'm mistaken about what you're asking. With that in mind:

This API is intended to be used by Web Applications. Web Applications are just web sites, though they may be provided with special UI by the user agent. With this in mind, it seems very unlikely that that a web app could exist without an origin¹.

In addition, the file handling APIs are only intended to provide a way to associate files with a web application (or web site, if you prefer), so they can show up in the Open with menu of your file explorer. The File System Access API specifies the details of native file system access on the web. However, before posting an issue there consider that the origin is the fundamental security primitive on the web. It's (roughly) analogous to an APP_ID on Android or iOS, and I suspect you might face an uphill battle trying to convince people to adopt a new security model allowing cross origin storage.

Additional Notes
It looks like hive can already be used in Flutter Web. Reading up on it, it sounds more closely related to IndexedDB than to file handling.

If you have a background in mobile development, it might be helpful to think of each instance of a browser as a different mobile device, and each origin (i.e https://example.com and https://otherexample.com) as different apps on that device.

---

¹ Note: Resource Bundles may let you install a web app without ever visiting the site. However, to the best of my knowledge, the point of signing the package is to let you confirm it came from the origin it claims to, so the web app would still be associated with an origin.

[fallaciousreasoning]

As I was writing my previous comment, I started wondering if you were actually making the argument that these APIs aren't suited to desktop application frameworks, such as electron. That is definitely something worth considering. However:

The purpose of this proposal is to design a system which allows Web Applications to be associated with files, not to design a generic system for letting any application open files, which is a vastly more difficult undertaking and somewhat outside the goals of WICG as I understand them. In addition, I don't see why Electron couldn't implement this API in it's current form, simply replacing Origin with App (being the electron application). I wouldn't be surprised if this was relatively straightforward to add to existing electron bundlers.

[kevlar700]

PWA is an unfortunate name, if they are really extended site caches?

It would certainly be nice if you did not need to waste space bundling electron to run an app with chrome/chromium or have it pre-installed in the few OS that have a package. Especially now that chrome OS is focusing on WPAs. Electron FS access does not cross many platforms either, unlike chrome/chromium.

I have read that Hive will likely support this API and currently supports indexedDB, with it's limitations. It also supports Android/IOS/Linux/Windows seamlessly with web (ignoring webs limitations).

Currently, I use Go for desktop filesystem access via localhost http and not electron or hive actually, because of these limitations.

I do not see it as vastly more difficult to extend this with a local only app api, personally? The browser is already capable of the difficult cross platform filesystem access on many platforms. I would argue that what is currently proposed contains security considerations, whereas this local only feature would pose very little risk.

I am not after generic file system access (often sandboxed these days) but simply web app files storage, associated with my flutter for web app, where localhost can become a secure origin, when certain conditions are met. So, I believe this may be the correct place for this discussion?

[dway123]

What is your general request, in one or two lines? I'm a bit confused what's being asked here.

I'm assuming that you generally would like this API to (1) be available on localhost, and (2) your proposed solution involves use of IDs for native applications.

(1) localhost

File Handling can only be used by installed PWAs (information from MDN and web.dev), where installed PWAs require secure context (including https). The w3c secure context specification states that secure context may include localhost, though implementation is up to the user agent. Therefore, it's possible that the specifications and explainers here are already amenable to your proposed use of localhost for file handling.

As you seem concerned about Chromium's treatment of localhost as secure context, I'd suggest filing a bug in http://crbug.com/new, (potentially with component Blink>SecurityFeature>SecureContexts, to request allowing localhost to be considered a secure context, or with component UI>Browser>WebAppInstalls, to request allowing localhost to be installable)

(2) IDs for native applications

The WICG (where this repo is hosted) only intends to discuss content on the web. For discussion about Electron (which supports native applications), I'd suggest an issue in https://github.com/electron/electron/issues.

[fallaciousreasoning]

I don't have much to add to what @dway123 has said but:

I have read that Hive will likely support this API and currently supports indexedDB, with it's limitations. It also supports Android/IOS/Linux/Windows seamlessly with web (ignoring webs limitations).

Reading this issue it sounds like the future of Hive on the web is IndexedDB. They note in the issue that [these changes mean that]:

code will work 1:1 with IndexedDB

I'd personally be quite surprised if they were to move to using the File System Access API instead, especially as this proposal exists precisely because the File System Access API is not (yet) a good fit for databases (though hopefully the proposals will be merged).

[mgiuca]

I agree with @fallaciousreasoning and @dway123 . It isn't clear what the request is here; this seems to be more general feedback on PWAs as an application platform rather than something specific to file handling.

I'd like to close this bug since there doesn't seem to be anything we can action here. Unless @kevlar700 can provide a specific example of what the problem is with the current model (i.e. please explain what it is that you think developers can't do with the origin-based model).