Re: [whatwg] metadata

[Anne van Kesteren]

On Mon, Apr 10, 2017 at 6:44 AM, Philip Jägenstedt  wrote:
> There is a very old bug for exposing the metadata:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=5755
>
> In order to make progress, there needs to be implementer interest. Although
> it may well fizzle out, a new issue
> https://github.com/whatwg/html/issues/new with the concrete suggested
> changes for HTML would be a good starting point.

Demonstrating there's interest in this through a popular JavaScript
library or two would help a lot.


-- 
https://annevankesteren.nl/

Re: [whatwg] metadata

[Philip Jägenstedt]

On Mon, Apr 10, 2017 at 8:38 AM Andy Valencia 
wrote:

> What follows is a first pass at addressing a missing ability
> when dealing with Internet streams, usually radio ones.
> Comments and suggestions are quite welcome; as my first
> attempt--ever--at submitting to this group, apologies if
> I've made any mistakes in how I've proceeded.
>
> Thanks,
> Andy Valencia
> Contact: https://vsta.org/contact/andy
>
> 
> Proposal for enhancement to HTML5  element to better support
> metadata provided by streams.
>
> # Background
>
> Browsers have an  element which can directly play streaming
> URL's.  When the stream is an Internet radio station, the stream
> almost certainly offers metadata; typically, the artist and track,
> and often an album cover URL as well.  While modern browsers can
> play these streams, there is no way to access this metadata.
>
> Media elements in modern browsers _do_ have the notion of metadata,
> but in current standards this is limited to static characteristics
> such as duration.  When listening to a radio stream, the metadata will
> change as successive tracks are played.
>
> # Stream Delivery of Dynamic Metadata
>
> A moderately detailed description of current practices in providing
> metadata is provided at:
>
> http://www.smackfu.com/stuff/programming/shoutcast.html
>
> (One detail glossed over in this page is that older streaming servers
> start their GET response with "ICY 200 OK" rather than a standard
> HTTP response.  This technically means the response is HTTP 0.9
> without headers; the headers are present, but must be processed by
> the application and trimmed from the start of the media stream
> in the GET response.  Apple Safari already declines to play 0.9
> media elements within a post-0.9 page, and there are signs that
> Chrome will follow suit.  Thus, accomodating this older mode should
> be considered optional.)
>
> Newer streaming server versions use a proper HTTP response, with
> the documented elements in the HTTP response header.
>
> Because the metadata is encoded in a general attribute=value
> format, a wide variety of metadata may be encoded.  By convention,
> at least the attributes "StreamTitle" and "StreamUrl" will be
> included in the response.  Also by convention, StreamTitle is
> structured as "Artist - Track Name".
>
> # API Considerations
>
> While listening to streams with metadata is a compelling application
> of web technology, it is probably a tiny percentage of the use
> of  elements.  Thus, this proposal describes a mechanism
> which leaves the default browser behavior unchanged.  It also
> gracefully degrades when presented to a non-implementing
> browser, still permitting stream play while in the existing
> non-metadata fashion.
>
> This proposal is designed with the current state of streaming,
> currently depending on the HTTP Icy-MetaData header element.  However,
> this specific detail is abstracted, in recognition that streaming
> technology could evolve in the future.  The intention is that this API
> will remain stable even if the details of metadata request and
> delivery change.
>
> As noted, current HTML5 media elements do have some metadata support.
> This API is also structured to permit these existing elements to
> participate in this API if desired.
>
> #  element changes
>
> These enhancements are activated when the  element has the
> new attribute "dynamicmetadata" present.  Without this attribute,
> no metadata request header is added to the stream HTTP request, and no
> other attributes of this proposal will be acted upon even if present.
>
> If the server response indicates support for dynamic metadata,
> on each metadata update, the  element's attributes are changed
> to reflect the latest received metadata.  For each "Attribute=Value"
> in the metadata update, an attribute "metaAttribute" with value "Value"
> will
> be added to the  element.  Previous metadata attributes which
> are not present in the latest update are left untouched.  The browser
> must verify well-formed identifier names for each Attribute, and
> quietly reject ill-formed names.  It can also apply checks on the
> Value.  (Implementors are reminded that the Value, because it encodes
> information such as names, might contain a wide range of character
> encodings.)
>
> The  element adds the hook "onmetadatachange", connecting to
> a function which is called on each update of metadata.  This
> function is called with an event, which includes the attribute
> "changed" with a value which is a list of Attribute names which
> are present in the update.
>
> # Example code
>
> 
> function new_meta(ev) {
> const changes = ev.changed;
> if (changes.indexOf("StreamTitle") >= 0) {
> const title = player.metaStreamTitle;
> const idx = title.indexOf(" - ");
> if (idx == -1) {
> // "Just a plain old piece of text"
> artist.textContent = title;
> 

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

[Brett Zamir]

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 
To: WHAT Working Group 
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 

[whatwg] metadata

[Andy Valencia]

What follows is a first pass at addressing a missing ability
when dealing with Internet streams, usually radio ones.
Comments and suggestions are quite welcome; as my first
attempt--ever--at submitting to this group, apologies if
I've made any mistakes in how I've proceeded.

Thanks,
Andy Valencia
Contact: https://vsta.org/contact/andy


Proposal for enhancement to HTML5  element to better support
metadata provided by streams.

# Background

Browsers have an  element which can directly play streaming
URL's.  When the stream is an Internet radio station, the stream
almost certainly offers metadata; typically, the artist and track,
and often an album cover URL as well.  While modern browsers can
play these streams, there is no way to access this metadata.

Media elements in modern browsers _do_ have the notion of metadata,
but in current standards this is limited to static characteristics
such as duration.  When listening to a radio stream, the metadata will
change as successive tracks are played.

# Stream Delivery of Dynamic Metadata

A moderately detailed description of current practices in providing
metadata is provided at:

http://www.smackfu.com/stuff/programming/shoutcast.html

(One detail glossed over in this page is that older streaming servers
start their GET response with "ICY 200 OK" rather than a standard
HTTP response.  This technically means the response is HTTP 0.9
without headers; the headers are present, but must be processed by
the application and trimmed from the start of the media stream
in the GET response.  Apple Safari already declines to play 0.9
media elements within a post-0.9 page, and there are signs that
Chrome will follow suit.  Thus, accomodating this older mode should
be considered optional.)

Newer streaming server versions use a proper HTTP response, with
the documented elements in the HTTP response header.

Because the metadata is encoded in a general attribute=value
format, a wide variety of metadata may be encoded.  By convention,
at least the attributes "StreamTitle" and "StreamUrl" will be
included in the response.  Also by convention, StreamTitle is
structured as "Artist - Track Name".

# API Considerations

While listening to streams with metadata is a compelling application
of web technology, it is probably a tiny percentage of the use
of  elements.  Thus, this proposal describes a mechanism
which leaves the default browser behavior unchanged.  It also
gracefully degrades when presented to a non-implementing
browser, still permitting stream play while in the existing
non-metadata fashion.

This proposal is designed with the current state of streaming,
currently depending on the HTTP Icy-MetaData header element.  However,
this specific detail is abstracted, in recognition that streaming
technology could evolve in the future.  The intention is that this API
will remain stable even if the details of metadata request and
delivery change.

As noted, current HTML5 media elements do have some metadata support.
This API is also structured to permit these existing elements to
participate in this API if desired.

#  element changes

These enhancements are activated when the  element has the
new attribute "dynamicmetadata" present.  Without this attribute,
no metadata request header is added to the stream HTTP request, and no
other attributes of this proposal will be acted upon even if present.

If the server response indicates support for dynamic metadata,
on each metadata update, the  element's attributes are changed
to reflect the latest received metadata.  For each "Attribute=Value"
in the metadata update, an attribute "metaAttribute" with value "Value" will
be added to the  element.  Previous metadata attributes which
are not present in the latest update are left untouched.  The browser
must verify well-formed identifier names for each Attribute, and
quietly reject ill-formed names.  It can also apply checks on the
Value.  (Implementors are reminded that the Value, because it encodes
information such as names, might contain a wide range of character
encodings.)

The  element adds the hook "onmetadatachange", connecting to
a function which is called on each update of metadata.  This
function is called with an event, which includes the attribute
"changed" with a value which is a list of Attribute names which
are present in the update.

# Example code


function new_meta(ev) {
const changes = ev.changed;
if (changes.indexOf("StreamTitle") >= 0) {
const title = player.metaStreamTitle;
const idx = title.indexOf(" - ");
if (idx == -1) {
// "Just a plain old piece of text"
artist.textContent = title;
track.textContent = "";
} else {
//  - 
artist.textContent = title.slice(0, idx);
track.textContent = title.slice(idx+3);
}
}
if (changes.indexOf("StreamUrl") >= 0) {
// Display album art
art.src = 

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

[Gregg Tavares]

I know this doesn't address your CD-ROM/USB stick situation but FYI...

for the dev situation there are many *SUPER* simple web servers

https://greggman.github.io/servez/

https://github.com/cortesi/devd/

https://github.com/indexzero/http-server/

https://docs.python.org/2/library/simplehttpserver.html (not recommended,
haven't tried the python 3 one)

https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb?hl=en
 (soon to be deprecated)

more here
http://stackoverflow.com/questions/12905426/what-is-a-faster-alternative-to-pythons-http-server-or-simplehttpserver

On Mon, Apr 10, 2017 at 4:36 AM, Jan Tosovsky 
wrote:

> On 2017-04-09 David Kendal wrote:
> >
> > ... 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...
>
> In this case the file structure is fixed so it can be exported as JSON
> file and then linked via the HTML header in every HTML file where it is
> needed. This structure is then directly available for the further
> processing.
>
> However, I am not sure this covers your use case.
>
> Jan
>
>

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

[Jan Tosovsky]

On 2017-04-09 David Kendal wrote:
>
> ... 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...

In this case the file structure is fixed so it can be exported as JSON file and 
then linked via the HTML header in every HTML file where it is needed. This 
structure is then directly available for the further processing.

However, I am not sure this covers your use case.

Jan

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

[Philipp Serafin]

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  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 
> wrote:
>
> > On 9 April 2017 at 11:51, David Kendal  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 . 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 

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

[Jonathan Zuckerman]

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 
wrote:

> On 9 April 2017 at 11:51, David Kendal  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 . 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
> >
> >
>

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

[Melvin Carvalho]

On 9 April 2017 at 11:51, David Kendal  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 . 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
>
>

[whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

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 . 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,

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
   <+grr> for security reasons I've switched to files:// urls instead