I've debated that reasoning in the security field and it just goes round-and-round in circles. There are legit cases to avoid this but less about security and more about scanning tools that poorly detect attempts to the loop-back as DNS rebinding attacks vs. an actual DNS rebinding attack which requires malicious code. So avoiding this can avoid some false positives from 3rd party scanners and having to get into silly arguments with people. There are some other obscure edge cases but they delve more into hypothetical scenarios and people can never seem to show a real world implementation of their theoretical attack. Besides, there is nothing stopping anyone from pointing any domain to 127.0.0.1 on their recursive servers or via /etc/hosts so if this is a risk then somebody is doing something very wrong.

Funny story though, I used to park wildcard sub-domains on 127.0.0.1 just to keep the bots off the load balancers and a customer said that we were running a vulnerable version of PHP. I said we had no installations of PHP anywhere in production. Turned out they were scanning one of my parked wildcard sub-domains and effectively were scanning their own laptop which had some old PHP web app running on it. That also told me they were also not validating certs.

> park wildcard sub-domains on 127.0.0.1

that sounds like a good practice -- why is this not done more often I wonder.

EDIT: on a second thought i am not so sure. I am not an expert here so I will not try to guess :)

In my experience most DNS admins abhor the idea of putting private IP addresses in public DNS space and it's simply not even an option they consider. I've used weird DNS tricks like this for years and never really encountered any issues, though. I currently have both my wireguard and private IP networks published to public DNS to make my life easier, for example.

I allow it. I use A records to set individual subdomains of my personal domain to individual Tailscale IPs. Then, when Tailscale is connected, all is well. Is this worth a telling off?

Private IPs should not be publicly routable. For one, you are no longer standards-compliant. If you want to depend on the IPv4 standard, you've already broken what you're trying to depend on.

I thought chrome was now blocking this anyways unless you specificly opt in with CORS.

It’s called Private Network Access and it’s still behind an experimental flag for now.

https://wicg.github.io/private-network-access/

https://developer.chrome.com/blog/private-network-access-upd...

Also ws/wss has no SOP/CORS which could be a problem, but that has nothing do with the domain blocking here.

The link you gave said it released 2 years ago in Chrome 94.

That's why I said "behind an experimental flag". Search for "private network" in chrome://flags.

I've got to ask - if you're doing local dev or whatever, what's so hard about turning ublock off for your dev site?

The logic seems ok for "out in the wild" cases - but ublock still let's you override stuff if you know what you're doing.

At a previous job I worked on a web-based file sharing app, and to share individual files we used a generic share icon from the font awesome project with appropriate labels.

We got a bug report from someone in the company that the share icon was missing, and after investigating we saw the other icons (for edit and delete) were visible but not sharing. Long story short, they used an adblocker with a setting to block social media sharing links (Facebook likes, Twitter follows, etc) and it was also removing our icon.

In this instance, maybe it'd be fine to turn it off for localhost and keep it on for staging but still...

In my experience, ublock breaks an awful lot of sites you have to use, such as your payment processor website, sales channel manager sites, etc. For me, at least, if a website seems to not be working quite right, I disable ublock and try again after a refresh.

I guess you could call those "trusted" sites perhaps.

Generally you want to use what your users use. Running common adblock lists as a dev can help identify /weird stuff/ early.

Plus genuinely the privacy list is good. Just not when it stops the ability to build good.

I was also confused on what's happening until I read this comment: https://github.com/easylist/easylist/issues/16372#issuecomme...

> Stupid example of why it may matter: say you installed LAMP on your computer several years ago, you're not using PHP frequently, and you haven't kept it up to date (so it probably contains a few nasty security vulnerabilities), but it still opens up on boot and listens on localhost.

> Now you open some website, it accesses 127.0.0.1, check for the LAMP vulnerability and exploit it if found. Congratulation, you have been pwn3d.

Interesting but very rare scenario?