Moin, Over the last few years there has been a gradual downgrading of support in browsers for running pages from the file: protocol. Most browsers now have restrictions on the ability of JavaScript in such pages to access other files.
Both Firefox and Chrome seem to have removed this support from XHR, and there appears to be no support at all for Fetching local files from other local files. This is an understandable security restriction, but there is no viable replacement at present. This is a shame because there are many possible uses for local static files accessing other local static files: the one I have in mind is shipping static files on CD-ROM or USB stick, but there is also the more obvious (and probably more common) use of local files by developers prototyping their apps before deploying them live to an HTTP server. This is an inconvenience to many web developers, and I'm far from the only one to complain about it. For instance, this from a very prolific reporter of Chrome bugs: > I've filed hundreds of Chrome bugs and I would rather would see this > fixed than any of them in <https://bugs.chromium.org/p/chromium/issues/detail?id=47416>. That bug was the number two most starred Blink bug in 2016. I'd like to see APIs that solve this problem securely, in a way that's portable across all browsers. I know this isn't trendy or sexy but 'single-page apps' are still in vogue (I think?) and it would be useful/cool to be able to run them locally, even only for development purposes. A proposed solution, though far from the only one possible: There should be a new API something like this: window.requestFilesystemPermission(requestedOrigin); which does something like - If permission was already granted for the specified requestedOrigin or some parent directory of it, return true. - If the current page origin is not a URL on the file: protocol, raise a permissions error. - If requestedOrigin does not share a root path with the current page origin, raise a permissions error. That is, a file with the name file:///mnt/html/index.html can request access to file:///mnt or to file:///mnt/html, but *not* to file:///etc, where it could read the local password file. - The browser displays an alert to the page user showing the name and path to the directory which has requested this permission. The user can then choose to allow or deny access. - If the user chose not to allow access to the files, false is returned or some other error is raised. - If they chose to allow access, return true. - For the remainder of the session (user agent specific), all files in the requestedOrigin directory, including the current page, have total read access (with Fetch, XHR, etc.) to all other files in the directory. requestedOrigin is allowed to be an absolute or relative URI. Some useful Fetch semantics for file: URLs should also be defined. I like this solution because it maintains portability of scripts between HTTP(S) and local files without too much extra programming work: if scripts only request relative URLs, they can both (a) detect that they're running locally from file: URLs, and request permission if so and (b) detect that they're running on HTTP, and make exactly the same API calls as they would on the local system. This is also a beneficial property for those using file:// URLs for development purposes. Of course, this is just one solution that's possible. I would welcome feedback on this proposal and any progress towards any solution to this very common problem. Thanks, -- dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/ <+grr> for security reasons I've switched to files:// urls instead
