Add a means to associate a PWA with a file extension

[marcoscaceres]

It's common on every OS to associate file extensions with some application (e.g., .psd opens in PhotoShop).

It would be great to figure out how we can associate files on a user's device to open with an installed web application.

[marcoscaceres]

More here: https://discourse.wicg.io/t/file-extension-association/2426

[kenchris]

cc/ @PaulKinlan

[AshleyScirra]

Some more thoughts on how this could work: have a manifest field similar to the following

{
    "file_extension_associations": {
        "abc": {
            "name": "My document format",
            "url": "path/to/open/abc",
            "icon": "/abc.png"
        },
        "def": {
            "name": "My other document format",
            "url": "path/to/open/def",
            "icon": "/def.png"
        }
    }
}

Notes:

• You can specify more than one kind of file extension association
• name is an optional description that can be used in the OS
• icon is an optional icon file
• url is the optional path to open when launching the PWA to open that file extension; if not provided, simply launches the default URL of the PWA
• all fields are optional, so a file extension association like "abc": {} specifies an association with default name (e.g. "ABC file"), default icon, and opens at the default URL of the PWA.

Another question is when should the user be asked if they want to set up a file extension association? Here are some ideas:

• have a user-gesture restricted permission that can be requested
• use browser heuristics, similar to deciding when to show the "add to homescreen" banner
• prompt upon using the following features:
  • downloading a file with a file extension that is present in the manifest (including local downloads using a@download)
  • drag-and-dropping a file with a file extension that is present in the manifest
  • choosing a file in a file input with a file extension that is present in the manifest

Basically any use of a local file with a file extension in the manifest is probably the ideal time to prompt the user to set up file extensions, since it is a strong indicator this would be useful to them if they're already using those kinds of files. That helps make it discoverable and prompt at the most useful time. But I think there ought to be another way to opt-in without having to do that, e.g. requesting a permission in a user gesture. To prevent abuse, the browser could automatically decline if there is not enough engagement (or in cross-origin iframe, etc).

[marcoscaceres]

Thanks! We also need to figure out how each OS allows for file extension registration and de-registration, specially if it can be done dynamically... this also needs to work with mime types via things like web share, etc.

[kenchris]

I am not sure this should necessarily be a part of this spec, though the work might extend it.

Comments @PaulKinlan ?

[mgiuca]

I didn't see this last year.

This is something we're very interested in at Google. @ewilligers

Some background: I worked on a very detailed (but now fairly obsolete) proposal for this in 2015:
https://github.com/mgiuca/ballista/blob/master/docs/explainer.md

(This eventually evolved into Web Share/Web Share Target.)

My current (vague) thinking on this is that we could use some variant of the (also obsolete) Writable Files proposal, and receive Writable File objects through Web Share Target.

[mgiuca]

If you want to be able to just read a file that was opened, Web Share Target could be extended to receive Blobs and that's about it. But if you want to write back to the user's file system (and I do), then writable file objects are necessary.

[AshleyScirra]

Would this be able to cover accessing entire folders too? Our PWA deals with very large user projects which are sometimes more efficient to save as a folder, so individual files can be updated, rather than needing to regenerate a single huge file every save. We had to release a download using NW.js to access these features via node APIs. It would be great if we didn't need to make a desktop download.

[mgiuca]

@AshleyScirra I'd like to get to a place where the user can grant access to an entire folder, so you can build web apps that work at the folder level (like git). This is a very powerful permission though so we'd need to carefully weigh it up. We did something like this in the proprietary Chrome Apps fileSystem API.

[raucao]

We actually were in that place with https://www.w3.org/TR/file-system-api/ before. My company used it in a popular app for video downloads/storage in Chrome for years. In fact, we would would still need that, and it was a bit of a shame that nobody else implemented it.

[mgiuca]

If I'm not mistaken, the FileSystem API was only providing sandboxed storage (i.e., although it presents a file-like view, it only presented the web app with a virtual file system, not allowing the app to mount a real directory from the host system, and thus was isomorphic to LocalStorage or some other API for persistent isolated storage of large amounts of data).

What I think we are talking about here (what chrome.fileSystem was) is an API to ask the user to nominate (through UI) a folder on their system, and provide persistent access to that non-sandboxed directory.

Either way, this is out of scope for this particular manifest issue, which is about file associations. But it is something we're interested in.

[raucao]

If I'm not mistaken, the FileSystem API was only providing sandboxed storage (i.e., although it presents a file-like view, it only presented the web app with a virtual file system, not allowing the app to mount a real directory from the host system

Yes, but that actually covers a lot of use cases, like for example @AshleyScirra's and ours.

and thus was isomorphic to LocalStorage or some other API for persistent isolated storage of large amounts of data).

There are some important differences between that API and e.g. localStorage/IndexedDB. For example it is not possible to get a filesystem URI for stored objects with the latter, meaning you cannot e.g. play audio or video directly from those.

Either way, this is out of scope for this particular manifest issue, which is about file associations.

True. Just wanted to register interest as well. :)

[AshleyScirra]

I think it's worth pointing out that Microsoft now support PWAs in the Windows Store, with full access to the WinRT APIs. Their approach appears to be reasonably secure and it solves all the problems we have, since the additional API surface exposes everything else we need for our desktop app to be able to do everything we want. A Windows Store app can declare file extension associations in its (equivalent to a) manifest. Upon installing the app, if nothing else claims to use those file extension associations, it automatically applies them. (I think if other apps claim to support them, it adds it to an "Open with" list.)

Additional features allow access to the file system, with an interesting permission model that is worth highlighting:

• Apps start off with no permission to any files or folders at all, except a few system defaults like the app install directory, and a temp folder for the app.
• The app can only access other files by bringing up a "file picker" dialog. If the user chooses a file, the app gains access to only that file. You can't access its folder, see other files in the folder, etc.
• The app can also access entire folders by bringing up a "folder picker" dialog. If the user chooses a folder, the app is granted access to the entire contents of that folder (recursively).
• In both cases the app is allowed to request to have these permissions remembered. This means the next time the app is launched it can automatically access the files without needing a dialog first. There is a limit to how much can be remembered and I think the platform is allowed to deny remembering the permission for any reason.
• The app may perform operations between files like moving and copying, but only within the whitelisted files and folders. (This can involve a bit of refactoring, e.g. you don't automatically have permission to write sibling files in the same folder as another file; you may have to use the temp folder instead.)

In other words file system access allows the minimum access possible after a user explicitly selects parts of the file system from UI, with the optional ability to remember this.

Hosted web apps in the Windows Store can already do this, and it seems to have passed Microsoft's security review, so it might be a model to consider for the wider web. On the other hand Microsoft may be relying to some extent on their ability to review and remove misbehaving apps from the store, which doesn't apply to the web.

[mgiuca]

Thanks for the info!

Moving this discussion to WICG/file-system-access#14 --- not sure if writable-files is the right place to host this but I want to keep this issue focused on file associations.

[ghost]

Any progress/updates here?

This is also something I would find pretty helpful.

[mgiuca]

@LukeWoodG We're (slowly) working towards this on a separate proposal site: https://github.com/WICG/file-handling

[ghost]

Cool, maybe I'll look into contributing a bit :) Thanks for the update!

[SeanBannister]

This is now possible using the file_handlers property in a web app manifest.

As of Chrome version 99 this feature is hidden behind a flag, to use it launch Chrome with the command line flag --enable-features=FileHandlingAPI, or go to chrome://flags/#file-handling-api and enable it.

Here's a demo with source code.

[mgiuca]

Let's keep this issue open until #1005 closes it.

[marcoscaceres]

Closing a #1005 closed.

And yes, using the file_handlers member in a web app manifest handles this... and I think file handlers is in the incubation spec.