W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2017

[whatwg] Accessing local files with JavaScript portably and securely

From: David Kendal <me@dpk.io>
Date: Sun, 9 Apr 2017 11:51:14 +0200
Message-Id: <6EDC81F3-95B0-4229-A3C5-76DBE548FF39@dpk.io>
To: WHAT Working Group <whatwg@whatwg.org>
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 Sunday, 9 April 2017 09:51:49 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 April 2017 09:51:50 UTC