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

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

From: Jonathan Zuckerman <j.zuckerman@gmail.com>
Date: Sun, 09 Apr 2017 12:23:42 +0000
Message-ID: <CAPP4rD874O0Qxzkz4gih_1RQsNYfRqAHf_R21SZO=8Ux+Q8ZDA@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>, David Kendal <me@dpk.io>
Cc: WHAT Working Group <whatwg@whatwg.org>
The solution most developers use is to run a simple web server that hosts
static content, it's a much simpler solution than the API you propose and
requires no changes to the spec. It doesn't address the CD-ROM use case,
though..
On Sun, Apr 9, 2017 at 06:11 Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

> On 9 April 2017 at 11: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.
> >
>
> Thanks for the pointer, I just starred this too.  I am currently hitting a
> wall with this issue as well.
>
> I have looked for a way to override this, but cannot find something.  As a
> consequence, I have switched to electron, which seems to have this feature.
>
>
> >
> > 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.
> >
>
> +1 looks like a good solution.  Another way would be to set a flag in the
> options.
>
>
> >
> >
> > 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 12:24:25 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 April 2017 12:24:25 UTC