Hacker News Reader

Comment by Guzba | Hacker News Reader

We use localhost to communicate with our desktop application which is commonly installed alongside our extension by users.

An example of how we use this communication channel is preventing both our extension and desktop apps from showing notifications on the same computer. Our apps are all about notifications so this would get unacceptable very fast. We ping our local desktop app via localhost to see if it can manage the notification, and show it with our extension if it isn't running.

Maybe if we limit it to just the local port we use? Seems like it can't hurt to try that too.

View on HN

I believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging

This may be well what needs to change, but in any case the message from Google should have been explicit about it instead of the dev involved having to create a blog post, hope it gets traction on HN and that someone here knows what the problem is.

Yes and no, I would be glad if Google in general could get much much better at this but in this specific case I'm sorry but http://* and localhost access is not a hidden small thing.

the docs are pretty explicit about it

But not their email.

Native messaging is extremely broken and has bad documentation. I never got replies to my bug reports about it and gave up and just used websockets.

Out of curiosity, what were the problems you ran into with native messaging?

So native messaging is fundamentally about opening a named pipe to a child process managed by the browser. I found that the pipe would silently break or time out. In the former scenario, the app was running but could no longer exchange native messages with the browser or extensions - chrome was just ignoring the pipe traffic. In practice I was able to use native messaging to spawn the executable but to actually talk with it I needed to use a websocket, kind of defeating the point.

I initially assumed I was doing something wrong but after a week or so experimenting with simple test cases I could not get it to work. Maybe it works fine on Linux and Mac but not Windows.

I initially assumed I was doing something wrong

We should probably have a weekly HN column with that title.

It might be a bit trickier, because if you hardcode the port in the manifest, the user wouldn't be able to change it?

Might be better than nothing I guess, but on the long term you'd need to add the port in settings and request the permission for localhost+port dynamically? But that's got another issue, e.g. last time I tried it [0] for my extension, Firefox didn't support dynamic URL permissions for URLs with ports.

[0] https://github.com/karlicoss/grasp/blob/f24378ebae68c22bea03...

You can probably get around this by setting up some DNS like localhost.pushbullet.com -> 127.0.0.1. It's probably not in the spirit of what they're asking for though, if it is indeed the problem.

If you have a half-decent router or firewall, this won’t work from outside the network.

My router (AVM FRITZ!Box) blocks DNS results for anything in the LAN range, as part of protection against rebind attacks.

But actually 127.0.0.1 seems unaffected:

    $ host 127.0.0.1.xip.io
    127.0.0.1.xip.io has address 127.0.0.1
    $ host 192.168.1.1.xip.io
    # no result

Huh? What kind of router would filter out 127.x responses by default? Also, this wouldn't work with DoH enabled which is where we're heading with browsers.

It’s about negating security mechanisms that rely on the request/target "origin".

Have you seen this fail? Drop box and spotify use this same trick, i assume it had wide support.

Can’t you setup a DNS entry on your domain that resolves to 127.0.0.1 that you reference instead of localhost?

Your resolver may not always permit this sort of thing, and that would just obfuscate what they're doing a step further which may come across as sneaky.

I doubt it is at all common in end user environments, but unbound for instance can be configured to prevent local IPs from being resolved in other domains. It's a good practice to follow in a datacenter environment if you're connecting out to hostnames you resolve from DNS you don't control.

Reply on news.ycombinator.com