Comment by est31 | Hacker News Reader

Comment by est31 | Hacker News Reader

IMO, the approach taken by Chrome and other browsers is over restrictive, basically killing off the file:// protocol. Already now it's impossible to load wasm files in the file:// protocol in Chrome, and I think this also had implications on using wasm in electon.

Ultimately, file:// is a great, cloud free method of having web pages and applications and it should stay that way instead of forcing everything to be networked and reliant on third party computers or domain names.

There are so many reports, documents, etc that live as non-networked html files. E.g. rust documentation (cargo doc --open) is generated as html files on-disk and then just displayed without the need for a webserver. Starting a localhost webserver is in fact less secure than file because now every user on the computer has access instead of just the users with read-access to the files. This has thankfully been fixed in Chrome OS though.

Responsive web apps are not the solution as they still need "seeding" via the network. Maybe some kind of standardized format where you have a glorified zip file with some metadata and when you double click it, it opens in the web browser which starts a web server in the background that runs a specially designated js in that zip file and which can accept usual fetch requests and has read access to the entire zip file. The browser's "UI" would then communicate with the server via well-known protocols.

Learning web programming is amazing, since you can just start writing a .html file and open it in a browser. There is no need to learn how go set up a local http server. Chrome truly is killing that experience; you can't even load javascript modules without http involved now outside of Firefox.

I really hope Mozilla doesn't "fix" this "vulnerability" by destroying the experience of people learning web programming like Google did.

Is it really that hard to run `python -m http.server` in your repository?

For someone getting started with programming? Very hard - it steepens the learning curve significantly

This. It's not only "open Notepad and save this text file, then open it in the browser".

Leave the complexity of learning what Python is, the 2 vs 3 issue, 32/64 bit versions, appending locations to your path, CLI, etc., for when the user is ready to start with dynamic web pages.

Luckly, the modern Python installers for Windows do all that.

Why should I install Python, if I want to do a bit of JavaScript? That's not really the point. Of course it's not complicated to setup XAMPP, LAMPP or whatever.

If you run Linux, you won't have to install Python - it will be there by default in almost every distribution. It hink this is why GP chose this example - there's a multitude of other options to instantly start a web server.

Edit: Here are 16 for example: https://gist.github.com/willurd/5720255

Most people are running Windows. That means most people trying to learn how to program are running Windows. I wouldn't want to figure out how to set up a web server on Windows myself, and absolutely wouldn't expect someone learning to program on their own to be able to art it up without getting frustrated.

Even for people on Mac and Linux, having to start by learning the terminal is a pretty big and unnecessary obstacle to just getting to writing some JavaScript. Sure, you and I think it's easy, but it's a completely different paradigm which requires practice to get comfortable with.

Even if you can be there right by someone learning to program, and help them set up a web server, they will have to remember how to do that when they want to play with programming while you're not there. That's actually quite a lot to remember when you don't yet understand what the commands mean; you think of it as "go to the directory, start SimpleHTTPServer", but they have to memorize the text they have to type. Maybe you're the one who cd'd into the correct folder for them, and they remember to type `python -M SimpleHTTPServer` in the terminal you created; they will then have problems they don't know how to solve when they go home and open a terminal and type the command and it doesn't work because they weren't in the correct directory.

Absolutely, I don't think we are in disagreement at all. I just wanted to mention the availability of simple web servers (on Linux, as you rightly state).

On topic, I agree that this is throwing the baby out with the bathwater. A compromise would perhaps be an explicit whitelist of allowed directories to serve via the file:// protocol, set by the user (while disallowing traversal upwards of these, of course).

Unless you're on a mac, or various Linux distros where python 2 is shipped by default still.

Mac comes with PHP, so you can do

    php -S localhost:3000 -t ./

And now you have: php -S localhost:3000 -t ./ on mac python -m http.server on some versions of linux, python -m SimpleHttpServer 8000 on others, and any of the above on windows.

How is that easier than putting file://path/to/foo.html into my browser window, as someone getting started in web development?

Please note, python is not available out of the box on Windows machines as in macOS, most of Linux distros.

Personally, as a person who used python in my programming job, I don't remember when for last time or even I have ever typed mentioned by you command to start a local server.

>Please note, python is not available out of the box on Windows machines as in macOS, most of Linux distros.

It (almost, kind of) is now, actually. Running python on a recent Windows 10 box without python installed will prompt you to install it.

https://devblogs.microsoft.com/python/python-in-the-windows-...

When I was about 13 I wanted to learn C++. I bought a book, installed the software from the CD and tried compiling the first example. It failed with a cryptic error about a file not being found. I gave up on programming for a number of years.

The book had failed to mention that I need to include the compiler in my PATH.

Honestly, if that's all that took you to give up on programming, it would not have gone on much longer anyway, especially with something like C++.

So what was I supposed to do with no expert on hand and no Internet? I went back to the bookshop and asked there. They didn't know either, so I returned the book.

I returned to programming when I learned about Quickbasic. That just worked and had an extensive help system that was suitable for self study.

I don't think that's very fair. Some people are extremely gifted mathematicians with incredible talent for algorithmic thinking, yet can be totally shut down by build configuration bullshit. It's a huge pain point in C-land.

Even worse, the code examples of (in)famous Bjarne Stroustrup were missing neccessary #include's and contained deadly typos.

I started learning HTML at age eight. No one in my family had experience with programming or using a terminal (there was an HTML book on discount at the book store). I was able to get started because it was dead simple, and only used tools I was already familiar with: the web browser, Notepad, and regular files.

I had exactly the same experience.

As much as I prefer the file protocol, an other option would be:

$ busybox httpd -p 8080 -f

-p for port (also possible to bind to specific IP: -p 127.0.0.1:8080), -f for foreground, also optional -h for served directory (default is .).

But the difference between doing almost nothing, a double click once and then it stays there even between restarts, to giving a specific command in a terminal is monstrously huge.

No it is not, and it has been easy to run a webserver on Windows for ages (Apache, Roxen, IIS, OmniWEB, etc).

However the barrier of entry is still higher than simply editing a .html file and loading it from the browser with file://

The question is, what is more important? Shouldn't this functionality be optional at the very least?

It ends up definitely being a tax on developer efficiency overall. It also makes web development more hostile to newbies because they have to figure out how to configure a server or hop into some third-party toolset on the web to start experimenting. With the tendency to ban use of new features on non-HTTPS origins (hi again, Chrome) a newbie developer will soon have to have both a server and a https cert before they can even start experimenting. If they host on a third-party https domain now third parties are responsible for malware that might get hosted there.

It just sucks.

Regarding HTTPS, localhost is considered a "secure" origin: https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

What are your thoughts on file:// URLs being opened/executed in a separate enclave from the network, with no access to the network?

This would allow the convenience of file:// and IMHO eliminate many if not all of the risks.

This won't allow to load images, files from CDN etc.

Correct. IMHO accessing the local filesystem is incompatible with accessing the network from a security standpoint.

I’m fine with having a very clear toggle to allow this behavior for developer types, but this should default to secure.

I think this summarizes the issue and is exactly the correct solution.

There's a lot of the comments along the lines of "just run python -m SimpleHTTPServer" - but doing that makes your computer just as vulnerable as allowing file:// in the first place, in theory. It's only the very awkwardness of doing that that makes it any safer. Instead of hiding this fundamental incompatibility between security and local accessibility behind a layer of inconvenience, better to drag it out into the open and label it and fully support it. While you're at it, you can slacken off some of the other restrictions in "local mode" as well.

A browser is the modern VM, for better or worse. It should function locally, standalone.

It would improve security, but ultimately as long as the file "enclave" can execute javascript, it has access to enough side channels to communicate any data it collects to the outside, so I guess the security concerns wouldn't be fully resolved.

Can you elaborate on these side channels?

One example: if two programs share the same CPU and have access to CPU resources, then one program could transmit information to another program by putting the CPU under load and removing the load again in some kind of morse code fashion. In computers with fans this would probably be noted by users but not every computer has fans. It's not a very high bandwidth way but enough to get ssh keys transmitted within a few hours of connection.

This case makes me wonder what if traditional filesystems would not separate files and directories. So that there would be just files which may have data and sub files. Then html file could include all js files etc. directly inside it so that we could give multi file permissions without leaking it to siblings.

The feature you are looking for already partially exists. Look for "extended attributes" (for most filesystems) or "alternate data streams" (for NTFS).

But in this case, it's much simpler to make a tar or a zip with the HTML and all necessary files. eg. that's how Python "eggs" work.

> I think this also had implications on using wasm in electon

It should not. Electron runtime is not a browser and developer can tweak its security settings.

I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix. For example: file some-page.html and directory some-page_files.

> It should not. Electron runtime is not a browser and developer can tweak its security settings.

Yes, that's what I meant. Sure you can override chromium, but you have to. https://github.com/adamvoss/electron-webassembly-hello/commi...

> I would suggest another idea for local files: grant access to folder whose name matches HTML file name, with suffix.

That would certainly help. It would restrict some multi-html-file projects a bit though that use shared resources. Probably can be helped by having a folder named html-fetchable-files or something.

Reply on news.ycombinator.com