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

[duanyao]

We should be aware of the security risks when recommand a "simple web 
server".


* Most (if not all) simple web servers don't block access from non-local 
hosts by default,
  which can leak users' files.  Although your firewall can block them 
for you, users do need unblock
  non-local hosts sometimes (e.g. test with a smart phone), so some may 
have whitelisted the

  server anyway.

* Even if non-local hosts are blocked, non-current users'(in the same 
OS) access can't be blocked
  easily by a web server. In contrast, file:// access is subject to 
file permission check.


* Most (if not all) simple web servers are hobby projects so probabaly 
lacks enough security audit.
  E.g. How urls like "/foo/../../../bar" are handled to prevent 
escaping from the root directory?


Those risks may be non-issue for experienced developers, but do affect 
newbie developers
and normal users. So In my opinion, it is much better to improve and 
standardize file-url

handling in browsers.

Regards,

Duan, Yao

在 2017年04月10日 04:33, 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

[Delfi Ramirez]

Dear all: 

I agree with the need to consider file://  ( or at least re-consider the
missing functionality) applicable to exec files / directories with HTML
documents, stored on physical devices ( like USBs or CD-DVDs), even it
might sound uselessness in the _cloudy_ times we live. 

This HTML docs MUST be viewable using a modern browser and listening to
DOM events. 

This required or proposed functionality ACCOMPLISHES well according to
standards, in the following scenarios: 

If the HTML document (static or don't )  links to any other docs
published at the WWW, ( as it was usual in DVDs and CDs from the ages of
the multimedia hype), like videos or external sites. 

Accessibility for earth places where you or the receiver needs to
storage and view HTML content, and where a direct connection speed may
not be as we know  (_ It comes to mind a friend who just came back from
her NGO's mission not far away from our places -- the term 'slow
connection' becomes there an euphemism_ ). 

Just mumbling , if it means for the goals. 

Kind Regards

### 

Note on Patrick's et al:  WWW is a protocol for the HTTP (S) via TCP/IP 

* _USB storage devices: fdisk, mkfs, mount/umount, file operations,
play a DVD movie and record a DVD-R media._
* _USB keyboards and USB mice._
* _USB webcams and USB speakers._
* _USB printers, USB scanners, USB serial converters and USB Ethernet
interfaces_...

A GENERAL USB DEVICE SHARING SYSTEM OVER IP NETWORK ACCOMPLISH THE WWW
PROTOCOL. 

---

Delfi Ramirez -- At Work

My digital signature [1]

0034 633 589231
 del...@segonquart.net [2] 

twitter: @delfinramirez [3]
 IRC: segonquart
 Skype: segonquart [4]

http://segonquart.net

http://delfiramirez.info
 [5]

On 2017-04-11 20:50, Patrick Dark wrote:

> David Kendal 於 4/11/2017 11:46 AM 寫道: On 11 Apr 2017, at 17:01, Domenic 
> Denicola  wrote:
> 
> Bingo. This mailing list is for developing technology for the world
> wide web, not for peoples' local computers. The World Wide Web includes 
> peoples' own computers. file:// is a URI
> scheme for exactly that reason. Every browser since WorldWideWeb.app
> for the NeXT has supported it, and every browser will support it
> forever, I hope. (Until it gets the  treatment, I suppose,
> since the current generation of web standards writers seem to regard
> the idea of platform stability with extreme contempt.)
> 
> You cannot escape this simply by redefining what you consider 'the web'
> to be.
> 
> (file:// is even 'world wide', to some extent. On computers with AFS
> installed, all URIs beginning with file:///afs/ will always resolve to
> the exact same files.)

The "world wide web" is the user-facing portion of the Internet. Files
on a CD or USB drive are not part of that.

 

Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info

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

[Jan Tosovsky]

On 2017-04-11 Patrick Dark wrote:
> Jan Tosovsky 2017-04-10 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...
> >
> > So basically you need
> > (1) JSON /* the folder structure stored in JavaScript objects */
> > (2) link to that JSON in your HTML file
> > (3) JavaScript in your HTML file, which renders JSON data to the page
> >
> > In my case both WebHelp pages and JSON is generated via XSLT from XML
> > source.
> 
> There's no reason to use JavaScript for displaying a table of contents.
> If the file structure is fixed, you can simply hard-code static XML
> entries in an XSLT stylesheet.

While slighty off-topic, my goal was to reduce the final HTML file size. The 
more pages, the larger ToC so the size of the complete set grows exponentially. 
If ToC is extracted and then just linked in every HTML page, it reduces the 
total size significantly. If documentation is shipped together with desktop app 
in the form of installer, it is better to keep it as small as possible.

> Granted, Google Chrome won't do XSLT transformations for local files,
> but that seems to be more of a browser deficiency than a specification
> issue. 

Sorry not being precise, that mentioned XSLT transformation (for my DocBook 
XML) is performed once off-the-browser, producing linked static HTML pages (and 
also JSON with the file hierarchy). I wanted to emphasize that generating JSON 
can be, in specific cases, nicely integrated into current generating workflow 
(the file structure is already available in DocBook XSL stylesheets for other 
purposes so it was quite easy to reuse it for generating JSON for ToC).

Jan

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

[Patrick Dark]

David Kendal 於 4/11/2017 11:46 AM 寫道:

On 11 Apr 2017, at 17:01, Domenic Denicola  wrote:


Bingo. This mailing list is for developing technology for the world
wide web, not for peoples' local computers.

The World Wide Web includes peoples' own computers. file:// is a URI
scheme for exactly that reason. Every browser since WorldWideWeb.app
for the NeXT has supported it, and every browser will support it
forever, I hope. (Until it gets the  treatment, I suppose,
since the current generation of web standards writers seem to regard
the idea of platform stability with extreme contempt.)

You cannot escape this simply by redefining what you consider 'the web'
to be.

(file:// is even 'world wide', to some extent. On computers with AFS
installed, all URIs beginning with file:///afs/ will always resolve to
the exact same files.)


The "world wide web" is the user-facing portion of the Internet. Files 
on a CD or USB drive are not part of that.

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

[Melvin Carvalho]

On 11 April 2017 at 18:01, Domenic Denicola  wrote:

> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
> Patrick Dark
>
> > I can't see this being addressed. The only good reason to distribute an
> application this way is because you want it to be confidential and there's
> no incentive to accommodate what one might call "walled gardens"
> in HTML because they naturally have a limited audience.
>
> Bingo. This mailing list is for developing technology for the world wide
> web, not for peoples' local computers.
>

That is one perspective of the world wide web.  But perhaps not a
perceptive shared by all.

Another view which I think is held by many, is that you should equally be
able to access public data on the web, data in the cloud and persona data
on your machine.

>
>
> You can use the same technology that people use on the web for local app
> development---many people do, e.g. Apache Cordova, Microsoft's
> Metro/Modern/UWP apps, or GitHub's Electron. But all those technologies are
> outside the standards process, and in general are not the focus of browser
> vendors in developing their products (which are, like the standards
> process, focused on the web). The same is true of file: URLs.
>
>
Yes, Im currently using Electron for this.  But would much prefer to use
the browser.  If there are browser have this restriction, I'd simply like a
way to turn it off.  It's a heavily requested feature, why wouldnt an open
source browser not be a suitable target for such an improvement (and
thereby gain market share).

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

[David Kendal]

On 11 Apr 2017, at 17:01, Domenic Denicola  wrote:

> Bingo. This mailing list is for developing technology for the world
> wide web, not for peoples' local computers.

The World Wide Web includes peoples' own computers. file:// is a URI
scheme for exactly that reason. Every browser since WorldWideWeb.app
for the NeXT has supported it, and every browser will support it
forever, I hope. (Until it gets the  treatment, I suppose,
since the current generation of web standards writers seem to regard
the idea of platform stability with extreme contempt.)

You cannot escape this simply by redefining what you consider 'the web'
to be.

(file:// is even 'world wide', to some extent. On computers with AFS
installed, all URIs beginning with file:///afs/ will always resolve to
the exact same files.)

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
 If one meets a powerful person […] one can ask five questions: what
   power do you have; where did you get it; in whose interests do you
   exercise it; to whom are you accountable; and, how can we get rid of
   you? Anyone who cannot answer the last of those questions does not
   live in a democratic system. — Tony Benn, Commons deb., 16 Nov. 1998

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

[Philipp Serafin]

Domenic Denicola  schrieb am Di., 11. Apr. 2017 um 18:01 Uhr:

> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
> Patrick Dark
>
> Bingo. This mailing list is for developing technology for the world wide
> web, not for peoples' local computers.
>

Doesn't that somewhat clash with the recent push to offline web apps and
the expectation/hope that pure HTML/JS/CSS might at some point be a
suitable replacement for native apps?

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

[David Kendal]

On 11 Apr 2017, at 12:55, Patrick Dark  
wrote:

> I can't see this being addressed. The only good reason to distribute
> an application this way is because you want it to be confidential and
> there's no incentive to accommodate what one might call "walled
> gardens" in HTML because they naturally have a limited audience. For
> example, if your application is being distributed via CD, that implies
> that that number of application instances will be limited to the
> number of physical media items, that the application will never be
> updated, and that the application therefore isn't particularly
> important.

I object strongly to this inference.

Let's approach this problem from the other end. This is the problem I'm
actually trying to solve, and I've concluded that the web platform,
distributed on CD-ROM, may be the best approach. Please suggest another
way to distribute something which is:

(a) stable, as in won't disappear when the publisher dies or goes out of
business and stops paying hosting bills;
(b) archivable, as in won't degrade significantly over the medium term
when stored;
(c) portable, as in not tied to any particular API;
(d) forward-compatible, as in will very probably run on future computer
architectures and operating systems in the long term, regardless of
system call or GUI API changes.

I am genuinely asking for suggestions for a better approach. HTML files
on CD are *vital* for certain kinds of large ebooks to survive the ages.
But if you want to make them interactive, you're hamstrung by the lack
of cross-browser support for XHR/Fetch for files on the same medium.

Bundling an HTTP server on the disc would break (c) and (d), though one
could depend on the capabilities of future software archaeologists to
simply run their own servers for the content.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
 The reason we had no idea how cats worked was because, since Newton,
 we had proceeded by the simple principle that essentially, to see how
 things work, we took them apart. If you try and take a cat apart to
 see how it works, the first thing you have on your hands is a non-
 working cat.— Douglas Adams

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

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Patrick Dark

> I can't see this being addressed. The only good reason to distribute an 
> application this way is because you want it to be confidential and there's no 
> incentive to accommodate what one might call "walled gardens" 
in HTML because they naturally have a limited audience.

Bingo. This mailing list is for developing technology for the world wide web, 
not for peoples' local computers.

You can use the same technology that people use on the web for local app 
development---many people do, e.g. Apache Cordova, Microsoft's Metro/Modern/UWP 
apps, or GitHub's Electron. But all those technologies are outside the 
standards process, and in general are not the focus of browser vendors in 
developing their products (which are, like the standards process, focused on 
the web). The same is true of file: URLs.

Re: [whatwg] Adding progress event for native ?

[Anne van Kesteren]

On Tue, Apr 11, 2017 at 2:44 PM, Mikko Rantalainen
 wrote:
> I see that https://xhr.spec.whatwg.org/ already defines ProgressEvent
> for XMLHttpRequest.
>
> Would it be possible to add "progress", "load", etc. events to normal
> form elements, too? Basically, I would like to do
>
>   form.addEventListener('progress', function (e) {...})
>
> and if the end user hits the Submit button, my progress listener would
> get called with ProgressEvent with lengthComputable, loaded and total
> attributes.
>
> If I have understood correctly, this does not make any information
> available to JavaScript that is not already available because JavaScript
> *can* already evaluate all form fields, use FileReader API to get all
> the files in file inputs and submit the form to the same action URL
> using XMLHttpRequest. In addition, browsers already implement all the
> required code because XMLHttpRequest needs that behavior.
>
> If listening for "progress" were allowed, I could implement my own form
> submission UI and still use regular forms that would work even without
> JavaScript.

It would leak new information cross-origin and due to redirects that
would be hard to distinguish from same-origin. You'd also have to
submit into some kind of  as otherwise you end up navigating
anyway.


-- 
https://annevankesteren.nl/

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

[Philipp Serafin]

Patrick Dark  schrieb am Di., 11.
Apr. 2017 um 13:55 Uhr:

> [...] The only good reason to distribute an application this way is
> because you want it to be confidential [...]
>

Another use-case would be to develop a HTML app that does not require
internet access.


>
> If you really want a private HTML-based application, you might consider
> a password-protected webpage. If the application isn't a throwaway app,
> you'll want to do that anyway, so there isn't anything lost from the
> upkeep required of maintaining an online server.
>

Why would I even want to run a server?

[whatwg] Adding progress event for native ?

[Mikko Rantalainen]

I see that https://xhr.spec.whatwg.org/ already defines ProgressEvent
for XMLHttpRequest.

Would it be possible to add "progress", "load", etc. events to normal
form elements, too? Basically, I would like to do

  form.addEventListener('progress', function (e) {...})

and if the end user hits the Submit button, my progress listener would
get called with ProgressEvent with lengthComputable, loaded and total
attributes.

If I have understood correctly, this does not make any information
available to JavaScript that is not already available because JavaScript
*can* already evaluate all form fields, use FileReader API to get all
the files in file inputs and submit the form to the same action URL
using XMLHttpRequest. In addition, browsers already implement all the
required code because XMLHttpRequest needs that behavior.

If listening for "progress" were allowed, I could implement my own form
submission UI and still use regular forms that would work even without
JavaScript.

-- 
Mikko

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

[Patrick Dark]

Jan Tosovsky 於 4/10/2017 5:38 PM 寫道:

On 2017-04-10 David Kendal wrote:

On 2017-04-09 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.

I'm not sure either, because I don't understand what you're proposing.
What feature of the HTML header enables this functionality? (For an
arbitrary number of files which may be wanted by an arbitrary number
of other files, and which could be very large.)

Imagine e.g. WebHelp composed of collection of static files with Table of Contents 
(ToC) in the left pane. It is not very efficient to generate large ToC into every 
single HTML file. If you extract ToC into a dedicated HTML page, it cannot be 
imported by standard means directly into another HTML page (analogically to XML 
Inclusions [1]). You have to use either IFrame, or, better, provide ToC as JSON file. 
JSON is kind of javascript which can be linked via the 

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

[Patrick Dark]

David Kendal 於 4/9/2017 4:51 AM 寫道:

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.


I can't see this being addressed. The only good reason to distribute an 
application this way is because you want it to be confidential and 
there's no incentive to accommodate what one might call "walled gardens" 
in HTML because they naturally have a limited audience. For example, if 
your application is being distributed via CD, that implies that that 
number of application instances will be limited to the number of 
physical media items, that the application will never be updated, and 
that the application therefore isn't particularly important.


If you really want a private HTML-based application, you might consider 
a password-protected webpage. If the application isn't a throwaway app, 
you'll want to do that anyway, so there isn't anything lost from the 
upkeep required of maintaining an online server.


As for development, it's trivial to install a local server using an 
offering like XAMPP and this gives you the power to test things like URL 
redirects that you can't test otherwise.