Re: [whatwg] Accessing local files with JavaScript portably and securely
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 Tosovskywrote: 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
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 > Denicolawrote: > > 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
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
David Kendal 於 4/11/2017 11:46 AM 寫道: On 11 Apr 2017, at 17:01, Domenic Denicolawrote: 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
On 11 April 2017 at 18:01, Domenic Denicolawrote: > 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
On 11 Apr 2017, at 17:01, Domenic Denicolawrote: > 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
Domenic Denicolaschrieb 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
On 11 Apr 2017, at 12:55, Patrick Darkwrote: > 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
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 ?
On Tue, Apr 11, 2017 at 2:44 PM, Mikko Rantalainenwrote: > 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
Patrick Darkschrieb 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 ?
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
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
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.