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

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-request@lists.whatwg.org wrote:

> Send WHATWG mailing list submissions to: whatwg@whatwg.org
>
> To unsubscribe, send an e-mail to: whatwg-unsubscribe@whatwg.org
>
> To subscribe, send an e-mail to: whatwg-subscribe@whatwg.org
>
> You can reach the person managing the list at: ian@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 <me@dpk.io>
> To: WHAT Working Group <whatwg@whatwg.org>
> Subject: [whatwg] Accessing local files with JavaScript portably and
> 	securely
> Message-ID: <6EDC81F3-95B0-4229-A3C5-76DBE548FF39@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,
>

Received on Monday, 10 April 2017 03:54:03 UTC