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.
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.
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.
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.
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.
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.
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.
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.