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

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

From: Yay295 <yay295@gmail.com>
Date: Wed, 19 Apr 2017 13:55:01 -0600
Message-ID: <CAH+HUiaWP59Ge2AD1Qb3E_u=A6gv7rmqVL_khbZLZnF-Ko8c-g@mail.gmail.com>
To: WHAT Working Group <whatwg@lists.whatwg.org>
Maybe a solution then would be to provide a way to request more storage
space?

On Wed, Apr 19, 2017 at 1:35 PM, Joshua Bell <jsbell@chromium.org> wrote:

> On Wed, Apr 19, 2017 at 8:23 AM, Roger H├ągensen <rh_whatwg@skuldwyrm.no>
> wrote:
>
> > On 2017-04-19 11:28, Anne van Kesteren wrote:
> >
> >> I already pointed to https://wicg.github.io/entries-api/ as a way to
> >> get access to a directory of files and <input type=file> as a way to
> >> get access to a sequence of files. Both for read access. I haven't
> >> seen any interest to go beyond that.
> >>
> >
> > Is this the Filesystem & FileWriter API ?
> >
>
> A small subset of the functionality specified in FileSystem was used by
> Chrome to expose directory upload. Support for that subset necessary for
> interop of directory upload has been implemented by Firefox and Edge. I put
> up the entries-api spec to try and re-specify just that subset. (It's a
> work in progress.)
>
>
> > This was added to Chrome/Opera under the webkit prefix 7 years ago, Edge
> > and Firefox has not picked this up yet (just the Reader part).
> > (as shown by http://caniuse.com/#search=file )
> >
>
> The market apparently demonstrates that a sandboxed file system storage API
> isn't high priority for browser vendors to implement.
>
>
> >
> > I avoid prefixed features, and try to use only features that latest
> > Edge/Chrome/Firefox support so that end users are more likely to not end
> up
> > in a situation where their browser do not support a app.
> >
> > And unless I remember wrong Firefox did support this at some point then
> > removed it again.
> >
> >
> > Take for example my soundbank app.
> >
> > A end user would want to either use a file selector or drag'n'drop to the
> > app (browser) window to add files to the soundboard.
> >
> > Let us assume that 30+ sounds are added (I don't even think the
> > filerequester handles multiselection properly in all browsers today)
> >
> > Would it be fair to expect the user to have to re-add these each time
> they
> > start/open the app? During a week that is a lot of pointless work.
> > Saving filenames is not practical, and even if it was there would be no
> > paths.
> >
> > And storing the sounds in IndexDB or localStorage is out of the question
> > as that is limited to a total of 5MB or even less in most browsers, 30+
> > samples easily consumes that.
> >
>
> You may want to check again. An origin typically gets an order of magnitude
> more storage than that for Indexed DB across browsers and devices.
>
> >
> > The ideal here is to make a html soundboard app locally (i.e file://)
> then
> > copy it as is to a webserver. Users can either use it from there (http://
> > or https:// online and/or offline) or "Save As" the document and use it
> > locally (file://) for preservation or offline use without server
> dependency.
> >
> > The only way to make this work currently is to make the user hand write
> > the path (full or relative) to each sound and store that in localStorage
> > along with volume and fade in/out.
> > But fade in and out is "faked" by adjusting the <audio> volume as CORS
> > prevents processing the audio and doing a proper crossfade between sounds
> > which is possible but locked down due to CORS.
> >
> > I can understand limitations due to security concerns, but arbitrary
> > limitations to functionality baffles me.
> >
> > I do not see much difference between file:// http(s):// besides one
> > allowing serverside data processing and http headers, but these days most
> > apps are entirely clientside. A sample editor can be written that is
> fully
> > clientside, even including mic recording normalizing, FX, the server is
> not
> > involved in any stage except delivering the .html file + a few lines of
> > headers. The web app itself is identical (i.e. hash/checksum identical)
> be
> > it http(s): or file:
> >
> > The benefit is that "the app is the source code" which is a ideal goal of
> > open source as anyone can review and copy and modify as they please.
> > And in theory it could run just as well truly offline/standalone as it
> > could online without the need for a local webserver or similar.
> >
> > I'd dare say that thinking of a web app as something hosted only from a
> > server via http(s) is a antiquated idea.
> > These days a "web" app can be hosted via anything, want to open a webapp
> > that is served from a cloud storage like Dropbox? Not a problem.
> > Well, almost not a problem. a cloud storage probably do not have the
> > proper CORS header to allow a sample editor to process sound from local
> > files or files stored on a different cloud service.
> >
> > And a soundboard or a sample editor is just two examples, a image or
> video
> > edit would have similar issues. OR what about a game with mod support?
> > Being able to drag'n'drop a mod onto a game and then have the game load
> it
> > the next time you start the game would be a huge benefit.
> > But currently this can not be done, the mod would have to be uploaded to
> > the server the game is served from, even if the game itself does not use
> or
> > need any serverside scripting.
> >
> > Or imagine a medical app that needs to read in CSV data, such a app could
> > work fully offline/local and load up the data each time it's started.
> > Storing the data in localstorage/indexDB would be limited to whatever
> else
> > is stored as far as size goes, and browsers can just wipe the local
> > storage/indexDB without warning. At least a local file stored on d:\docs\
> > is safe from vanishing.
> >
> > Even if the app itself is online and served from a server you still can't
> > have it load a list.CSV from d:\docs\ when starting it for example. And
> > IndexDB/localStorage is limited to around 5MB total for that domain.
> Maybe
> > there is a desire to switch between datasets list1.csv and list2.csv and
> > list3.csv and before you know it you open xray.png enhance a area and
> save
> > that change (in localStorage as you can save the path and a zoomvalue you
> > have to save the entire image instead) and suddenly list1.csv get deleted
> > from localStorage for that domain. And these are limitations to http(s):
> > and not just file:
>
>
> One of the ideas you're highlighting here is around allowing web apps to
> access local files in a read/write fashion, possibly in a persistent way.
> There's been some discussion about that at:
> https://github.com/WICG/writable-files
>
> ....
>
> On the topic of file:// behavior - the history of support in browsers is
> instructional here. Early browsers (naively) assumed that local content
> could be fully trusted, more so than content served over HTTP (think IE
> security zones). As the web security model has evolved, the capabilities
> granted to file:// content has become more and more restricted over the
> years. I expect that trend to continue rather than reverse.
>
>
>
> >
> >
> >
> > --
> > Unless specified otherwise, anything I write publicly is considered
> Public
> > Domain (CC0).
> > Roger H├ągensen,
> > Freelancer, Norway.
> >
>
Received on Wednesday, 19 April 2017 19:55:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 19 April 2017 19:55:36 UTC