I support such an approach and have found the usual "use a server"
response a bit disheartening. Besides the stated cases, I believe it
should just be easy for new programmers, children, etc., to try out
simple projects with nothing more than a browser and text editor (and
the console is not enough).
Another use case is for utility web apps to be shared such as doing text
replacements offline without fears of privacy/security that the text one
pastes can be read (if remote file access can optionally be prevented).
I also support an approach which grants privileges beyond just the
directory where the file is hosted or its subdirectories, as this is too
confining, e.g., if one has used a package manager like npm installing
in root/node_modules, root/examples/index.html could not access it.
FWIW, Firefox previously had support for `enablePrivilege` which allowed
local file access (and other privileged access upon consent of the user)
but was removed: https://bugzilla.mozilla.org/show_bug.cgi?id=546848
I created an add-on, AsYouWish, to allow one to get this support back
but later iterations of Firefox broke the code on which I was relying,
and I was not able to work around the changes. It should be possible,
however, to implement a good of its capabilities now in WebExtensions to
allow reading local files (even optionally from a remote server) upon
user permission though this would not work around the problem of file://
URLs just working as is.
For one subset of the local file usage case (and of less concern,
security-wise), local data files, I also created an add-on WebAppFind
(though I only got to Windows support) which allowed the user to open
local desktop files from one's desktop into a web app without a need for
drag-and-drop from the desktop to the app.
One only needed to double-click a desktop file (or use "Open with..."),
having previously associated the file extension with a binary which
would invoke Firefox with command line arguments that my add-on would
pick up and, reading from a local "filetypes.json" file in the same
directory (or alternatively, with custom web protocols where sites had
previously registered to gain permission to handle certain local file
types), determine which web site had permission to be given the content
and to optionally be allowed to write-back any modified data to the
user's supplied local file as well (all via `window.postMessage`). (The
add-on didn't support arbitrary access to the file system which has some
use cases such as a local file browser or a wiki that can link to one's
local desktop files in a manner that allows opening them, but it at
least allowed web apps to become first-class consumers of one's local data.)
But this add-on also broke with later iterations of Firefox (like so
many other add-ons unlike, imv, the much better-stewarded
backward-compatible web), and I haven't had a chance or energy to update
for WebExtensions, but such an approach might work for you if
implemented as a new add-on pending any adoption by browsers.
Best wishes,
Brett
On 10/04/2017 3:08 AM, whatwg-requ...@lists.whatwg.org wrote:
Send WHATWG mailing list submissions to: wha...@whatwg.org
To unsubscribe, send an e-mail to: whatwg-unsubscr...@whatwg.org
To subscribe, send an e-mail to: whatwg-subscr...@whatwg.org
You can reach the person managing the list at: i...@hixie.ch
When replying, please edit your Subject line so it is more specific
than "Re: Contents of whatwg digest..."
When replying to digest messages, please please PLEASE update the subject line
so it isn't the digest subject line.
Today's Topics:
1. Accessing local files with JavaScript portably and securely
(David Kendal)
2. Re: Accessing local files with JavaScript portably and
securely (Melvin Carvalho)
3. Re: Accessing local files with JavaScript portably and
securely (Jonathan Zuckerman)
4. Re: Accessing local files with JavaScript portably and
securely (Philipp Serafin)
----------------------------------------------------------------------
Message: 1
Date: Sun, 9 Apr 2017 11:51:14 +0200
From: David Kendal <m...@dpk.io>
To: WHAT Working Group <wha...@whatwg.org>
Subject: [whatwg] Accessing local files with JavaScript portably and
securely
Message-ID: <6edc81f3-95b0-4229-a3c5-76dbe548f...@dpk.io>
Content-Type: text/plain; charset=utf-8
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,
