Re: [whatwg] Accessing local files with JavaScript portably and securely

To set aside the previous thread, I'd like to make a renewed call for
input on my actual proposal, including counter-proposals, potential
flaws in my design, etc.

Then perhaps we can make some progress here.

dpk

On 9 Apr 2017, at 10:51, David Kendal <me@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.
> 
> 
> Thanks,
> 
> -- 
> dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
>    <+grr> for security reasons I've switched to files:// urls instead

Received on Friday, 14 April 2017 21:43:45 UTC