Hacker News Reader

Comment by modeless | Hacker News Reader

An underused option is to include a local HTTP server in your native app and open it in the user's default browser. This avoids some of the resource consumption and security issues that make Electron bad, but still lets you integrate native code with a web UI.

I wrote a little framework for this: https://github.com/jdarpinian/web-ui-skeleton

View on HN

I've worked on some applications like this, and it works pretty well. But be aware that a port on localhost is accessible to any local user - depending on the application you may need to prevent other users accessing it.

Running inside a real browser also limits the keyboard shortcuts you can use, because you don't want to clash with the browser's own shortcuts.

Weirdly, Windows makes it easier to do this securely in that you can do NTLM authentication to authenticate local users (maybe MacOS as well, I believe internally it runs its own Kerberos server for the local machine).

AFAIK you can only do this if you disable the local loopback check that prevents windows auth from passing credentials to local host webservers.

Why did they put that in in the first place? To stop cracking of local passwords?

Can't this concern be easily alleviated by the backend requiring credentials, and sending them along from the frontend? Getting around this as an attacker means already possessing enough rights to not need sniffing the traffic to the backend. Or is there more required?

It can, but getting the credentials to the browser & storing them there isn't entirely simple. If you launch a browser process to a URL containing a token, an unprivileged local attacker can see it in the command line arguments (at least on some platforms) and copy it. That can be mitigated by launching the browser with a file:// URL which uses an HTML meta redirect to give the browser the token.

The obvious way to keep the browser authenticated is a session cookie. But cookies are shared between all ports on a domain, so a local attacker who tricks you into visiting another localhost service in the same browser can steal the cookie. localStorage doesn't have that issue, but it's not so convenient for authenticating requests.

You can capture most keyboard shortcuts in the browser these days, and the native server side can handle registration of global keyboard hooks if your app needs those.

I'm thinking more of the user experience if you take over shortcuts people already use for their browser.

Usually if it's already local, you don't mind localhost connections. If you do, you can negotiate a shared cookie or other auth mechanism. Otherwise, you should at least check the host header to prevent DNS rebinding attacks.

This is how Electron style apps should work, instead of wrapping an entire browser instance around each app to maintain the illusion of it not being at all web based.

They are called PWAs

PWA refers to the client-side app only. They are not related.

How do you figure? You can locally host or package a PWA same as Electron. Chrome at least is closing the gap in capabilities too.

No. I want to be able to Ctrl-S and it save the changes I made to the file (for example, but this is the most annoying thing for me) That doesn't work with actual browser.

Yes it does. Just preventDefault() the keyDown event.

And now you start a download and the modified file goes into the User's download folder as file(n).whatever instead of wherever they opened it from.

No, remember that you have a local server running native code. The server can handle writing the file to any path you want.

But if you do that, you also have to handle file opening from the native local server side too (because browser file browser will not tell you actual file path). And of course, that dialog won't be a modal of the browser.

This is getting weird very quickly (not to mention that Ctrl-S in browser windows saving file without confirmation is a UX I wouldn't want to use)

> And of course, that dialog won't be a modal of the browser.

There are several decent options. You could build a modal that displays a view of the file system sourced from the server. Or you could pop a real native file dialog from the server, and I'm betting it's possible to either make it a real modal of the browser window or do a good enough simulation depending on platform. Or in the future you could use the native file system API that is currently in origin trial.

I submit that this is not weirder than most cross-platform UI toolkits that implement their own whacky replacements for the native file dialogs.

Is there a good way of doing SSL with this that doesn’t require hacking self signed certs into the users browser? A lot of newer web APIs are requiring SSL.

You can access those APIs using SSL from the server, which then relays the results to the client.

Most modern browsers should consider http://127.0.0.1/ or http://[::1]/ as trustworthy.

See https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy

In my experience, it's http://localhost that is considered secure, but not http://127.0.0.1. This may have changed since I last checked.

I believe that Chrome treats all localhost connections as secure now. Not sure about other browsers.

> security issues that make Electron bad

Exposing a HTTP port with application state is a million times worse for security

The server binds to the loopback interface, so it's not exposed to the network at all. Then as long as you use CSRF protection and an appropriate Content Security Policy it is safe.

But if you want to interact with local file-system (like open dialog) it start to get complicated.

Reply on news.ycombinator.com