8 ms·
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 commun
by Guzba 6y ago
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.
- paulirwin 6y agoI believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/nativeMessaging
- rosywoozlechan 6y agoThis 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.
- maartn 6y agothe docs are pretty explicit about it
- ldiracdelta 6y agoBut not their email.
- nolok 6y agoYes 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://* http://* and localhost access is not a hidden small thing.
- kevingadd 6y agoNative 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.
- pvg 6y agoOut of curiosity, what were the problems you ran into with native messaging?
- kevingadd 6y agoSo 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.
- pvg 6y agoI initially assumed I was doing something wrong We should probably have a weekly HN column with that title.
- VWWHFSfQ 6y agoYou 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.
- withinboredom 6y agoIf you have a half-decent router or firewall, this won’t work from outside the network.
- viraptor 6y agoHuh? 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.
- fuzzy2 6y agoIt’s about negating security mechanisms that rely on the request/target "origin".
- mappu 6y agoMy 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
- bmm6o 6y agoHave you seen this fail? Drop box and spotify use this same trick, i assume it had wide support.
- deleted 6y ago[deleted]
- karlicoss 6y agoIt 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/f24378ebae68c22bea03e72fa8cfc6da777adcb0/src/js/permissions.js#L15-L24 https://github.com/karlicoss/grasp/blob/f24378ebae68c22bea03...
- erikrothoff 6y agoCan’t you setup a DNS entry on your domain that resolves to 127.0.0.1 that you reference instead of localhost?
- skuhn 6y agoYour 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.