Comment by GeneralMaximus | Hacker News Reader

Comment by GeneralMaximus | Hacker News Reader

Parent Full thread

I'm enamored with the idea of writing desktop applications with web technologies, but I'm not enamored with the idea of running a node.js instance locally for every such desktop application.

What I would like to see is a "privileged mode" Chromium (or Firefox) that would let applications break out of the browser sandbox and directly perform operations such as filesystem I/O. Privileged Mode Chromium would obviously be a huge security threat if it's allowed to run any old code, so it would be wise to prevent it from downloading and executing scripts over the network, or maybe have some kind of script signing support in place so that the only scripts allowed to execute are the ones with the app developers' signature on them. Or maybe I'm talking out of my ass here and what we have right now works just fine. Feel free to correct me here.

Also, one question. Isn't the node.js instance serving my application visible to other applications on the same system? Can't a malicious application take advantage of this fact and cause my app to misbehave?

(Offtopic: I must point out an irritating and potentially harmful design trend that is emerging as a result of Twitter Bootstrap's popularity: the top navigation bar that stays in place as you scroll downward. It wastes precious screen space, looks ugly and doesn't add anything of value to the website. Why is it so important that I be forced to look at your website's logo and navigation bar all the time? I'm not picking on the AppJS developers here; this is a general sentiment directed towards all the designers who embrace this terrible trend.)

    What I would like to see is a "privileged mode" Chromium
    (or Firefox) that would let applications break out of
    the browser sandbox and directly perform operations such
    as filesystem I/O.

This is exactly what Microsoft HTML Applications do (available since IE 5). In other respects, I'm not a big fan of Internet Explorer, but this is one thing I think it did amazingly right, and way before anybody else. I was very excited to see the headline, and then horribly disappointed to discover that what they're offering is Not As Good as 13-year-old Microsoft technology.

It may have been a very good idea, but the sandbox implementation was shoddy, and 'Local Machine Zone' exploits are one of the main reasons IE has such a terrible security reputation. So other browsers should be wary about introducing a 'privileged mode'.

People can always install untrusted applications written in C. Why should the fact that your application is written in HTML+JavaScript make any difference? If it's just another native application; the implementation is unimportant to the end user.

Now, security is important, and it would be nice if all applications could be verified as to security. But they aren't. So while it would be good to figure out how to properly sandbox desktop HTML+JavaScript applications, I don't see as how failure in that regard should retard their adoption anymore than it retards the adoption of native applications written in C.

The obvious different is that you don't want to execute arbitrary C code just because a compromised ad network is serving malformed HTML. The ease of attack is much greater on the web.

Mozilla has used "no IE-like privileged mode" as a marketing point in the past. There's obvious benefits, but I hope any modern browser is going to be careful about the sandbox is implemented.

You're comparing incomparable things. Serving a web page in an unsecured environment is an obvious security problem, but completely unrelated to whether you have written a native application in HTML+JavaScript or something more traditional like C.

Would the C version of your native desktop app download code from an online ad network? Then it is just as problematic as a web app in an unsandboxed browser. If the C implementation of your desktop app wouldn't do that, then the HTML+JavaScript implementation of the same application shouldn't either, and there is no problem.

Actually, you the one making this strange comparison to C code.

My point is simple: IE's sandbox was broken repeatedly, creating a bad reputation and scoring marketing points for other vendors.

Mozilla and its successors, Firefox and Thunderbird are actually built on XUL[1], which is an XML-based UI description language which can be mixed with HTML and SVG, styled with CSS and programmed just like HTML with JavaScript. Then there's the xulrunner, which lets you write standalone apps on this tech. It's never taken off much, but I don't know if that's down to flaky implementation or just lack of interest. (if you don't like XUL, just use a minimal amount of it to embed your HTML app)

[1] I'm not sure what the current status is, but I think they want to phase it out?

XUL is not html, and you'll have to hit the docs every time you need something. Also, debugging XUL is a pain. XUL is pretty ancient too, so that probably doesn't help either.

Sticking with plain jane html is definitely the better approach, however I doubt the XUL implementers would have ever known that back in the year 2000. There's still a bunch of tools for XUL, but fairly rusty: http://xul.sourceforge.net/

AppJS does not use http server to handle requests. It only simulates client/server.

It creates a custom scheme named appjs:// and handles are requests with this scheme manually without any server listening.

Actually, there's already filesystem I/O in HTML5.

I'm not sure what you mean by "privileged Chromium mode". You could very well just use the regular mode that exists in your browser to create a full-blown application. Of course there's always contraints, because you only have available the HTML5 api, but now days you can do lots of stuff with it - it pretty much has everything a regular app would need (disk IO, network IO, UI, etc.).

As far as security goes, the Chromium sandbox is much more secure than any other code you would be writing yourself - after all it's the same thing that runs inside your Chrome browser, which is world-class secure.

For the Node instance, I also don't see any issue here. Sure the web-server that is initialized on your local machine is visible across your local network, but you can simply secure it just as you would with any regular web-application.

Re: "the Chromium sandbox is much more secure".

Have seen code targeting IndexedDB in Chromium that crashed the browser, and in one instance rebooted the machine, each and every time it was called.

Link? This interests me.

What you're describing is well in line with Mozilla's Apps, WebAPI and even Boot2Gecko projects.

Firefox Nightly includes the ability to install an app (a webapp with a manifest file) and you get a runnable program in a platform-specific location. The WebAPI project is expanding the web platform to include other needed capabilities, driven in large part by the Boot2Gecko OS where everything is HTML, JS and CSS.

For each API, people are working out how the permissions should work. The general goal is to expand capabilities while keeping it as secure as possible without being annoying.

AppJS uses node.js to have node advantages:

* Node is modular so apps you develop with appjs. * Node built-in modules like FileSystem are necessary for desktop apps with the advantage of better implementation than Chromium alternatives. * Node is popular among developers. * Node has lots of third-party modules for nearly everything

Check out macgap https://github.com/maccman/macgap

If you are using WebSockets for communication between Node.js and WebView then you can setup the server so that it accepts only one connection at a time. Also, when app starts you could generate random hash and pass it to Node.js and WebView environments. When Node.js server receives request that does not contain the valid hash then just drop the connection.

AppJS does not use http connections. It only simulates it. It uses a custom scheme (appjs://).Whenever a request with this scheme is made, AppJS routes it to your javascript code in node.js.

You just described NaCL.

Reply on news.ycombinator.com