> Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost.
It makes no sense to me. Unless someone knows of a better reason, I'm of the opinion that this change should be reverted.
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.
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 :)
> 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?
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.
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...
I guess you could call those "trusted" sites perhaps.
Plus genuinely the privacy list is good. Just not when it stops the ability to build good.
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.
Oh I see what you mean. The default blocking behavior in Chrome 94 only applies to public non-secure contexts. We’re talking about a stricter form applied to secure contexts here.