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

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

From: Philipp Serafin <phil127@gmail.com>
Date: Sat, 15 Apr 2017 13:09:54 +0000
Message-ID: <CAMaigVkcvzSOecDyJYFYToN_FHgUpQdZnHrMmC1tXXLL7ErtrQ@mail.gmail.com>
To: Roger Hågensen <rh_whatwg@skuldwyrm.no>, whatwg@lists.whatwg.org
If I see this correctly, we're currently talking about two different
use-cases for file/directory access:

1) Giving HTML apps the ability to "open" and edit local user-provided
files and directories in a similar manner to desktop apps (the soundboard
example)

2) Loading (parts of) the app itself from a local filesystem, possibly
without any network access being available at all (the CD rom example).

Maybe the security would be easier to handle if dealt with both use-cases
separately. I think both use-cases have different requirements,
non-requirements and "prior art":

1) requires that file/directory paths be passed by the user dynamically,
but does not (to my knowledge) require that the app accesses any paths
*not* given by the user (if you treat a directory as "all paths within
it"). Maybe you could build upon the existing capability-based system used
for file input here: E.g. some extended file control that allows an app
enumerate/write access to the selected file or directory, but doesn't allow
it access to anything else.

2) sounds like an extension of offline apps to me. Maybe this could be
solved by defining some kind of package format for service workers and
cached resources, so service workers can be installed without any network
access.

Roger Hågensen <rh_whatwg@skuldwyrm.no> schrieb am Sa., 15. Apr. 2017,
14:08:

> On 2017-04-15 11:58, David Kendal wrote:
> > On 15 Apr 2017, at 01:09, Patrick Dark <
> whatwg.at.whatwg.org@patrick.dark.name> wrote:
> >
> >> So if you put this file in the Windows Downloads directory, then it
> >> has read access to all download files even though they aren't related?
> > Ah, well, that's why you have to ask the user. The prompt should make
> > clear that this is a possibility -- something like:
>
> Patrick makes a good point.
>
> For example asking a user if it' sok for the HTML document to access
> stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most
> uses will do?
> Just click OK, after all "they" have nothing important in that folder,
> their stuff is in "Documents" instead.
>
>
> Maybe a html document could have a offline mode parameter of some sort,
> if the document is in the temp folder then it is put in a virtual
> subfolder and can only access folders/files under that.
>
> If it is not in the temp folder (or other such similar folder)
> then a list of folders need to be provided.
>
> For example
> d:\Myhtmlapp\index.html (automatic as the document can access itself)
> d:\Myhtmlapp\js\ (the javascript linked in the document is stored here)
> d:\Myhtmlapp\css\ (the css linked in the document is stored here)
> d:\Myhtmlapp\sounds\ (sounds to be indexed/used by the document, i.e a
> soundboard)
>
> This way a htmlapp will work as a single file document on it's own (as
> it does today) or with specified subfolders. It would not have access to
> anything outside of the specified subfolders or files.
> Open file and Save File requesters on the other hand could be allowed
> outside those folders as those are directly controlled by the user.
> Indexing/parsing of files in non-app subfolders is another issue that
> will require a different take (listing filenames/sizes/dates).
>
>
> How to specify subfolders I'm not sure, document header? Or maybe
> leverage the current work on for Offline Webapps which uses a separate
> file?
>
> Browsers also need to be make sure that a file is not added to the temp
> folder that enables access to sub folders. (The root of the temp folder
> should always be treated as special regardless.)
>
>
> --
> Roger Hågensen,
> Freelancer, Norway.
>
Received on Saturday, 15 April 2017 13:10:36 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 15 April 2017 13:10:36 UTC