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

Note also that the HTTP server solution requires you to ship a binary (the
server) with your files, therefore sacrificing platform independence and
requiring the user to run an untrusted binary, all just to show some HTML
files.

Jonathan Zuckerman <j.zuckerman@gmail.com> schrieb am So., 9. Apr. 2017,
14:23:

> 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 13:49:15 UTC