On 9 April 2017 at 11:51, David Kendal <m...@dpk.io> wrote:

> 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.

I thought I'd share this design issues note by Tim Berners-Lee, on this
topic, which some my find interesting


"It is actually pretty interesting to live on the edge, or more
specifically on the intersection of these worlds where you can address the
same files both as local files and as resources on the web. Why do both?
Well, different things work better in different worlds"

> Thanks,
> --
> dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
>    <+grr> for security reasons I've switched to files:// urls instead

Reply via email to