Document reasoning to block DNS to 127.0.0.1
1–10 of 45 posts
Re: Document reasoning to block DNS to 127.0.0.1
#2The issue might be more interesting to read: https://github.com/easylist/easylist/issues/16372
Re: Document reasoning to block DNS to 127.0.0.1
#3This is not the right way to block domains that resolve to local addresses even if that was something you desired to do.
If you know the IP you want to block you should just block on the IP instead of chasing down every possible address even though addresses can change at any time.
Re: Document reasoning to block DNS to 127.0.0.1
#4This is the explanation given by the person who committed this change:
> 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.
Re: Document reasoning to block DNS to 127.0.0.1
#5The issue might be more interesting to read: https://github.com/easylist/easylist/issues/16372
Ok, changed from https://github.com/easylist/easylist/commit/68d7a669e6cdc270.... Thanks!
Re: Document reasoning to block DNS to 127.0.0.1
#6Re: Document reasoning to block DNS to 127.0.0.1
#7Has this user’s GitHub account potentially been compromised?
The reasoning they give makes no sense; their style of writing also doesn’t match previous commits that they’ve made. Maybe looking too deep into this, but this commit makes absolutely 0 sense and should be reverted.
Re: Document reasoning to block DNS to 127.0.0.1
#8Annoying, but understandable. There's a reason localhost gets special treatment, as do many other local addresses. Local dev sites easily form a fingerprint that you don't want trackers to be able to use.
I'm not sure why this applies to first party browsing, though. In its current form (https://github.com/easylist/easylist/blob/master/easyprivacy...) several of these domains got the $third_party modifier which should make CORS fail, and that should resolve most of the fingerprinting risk. I'm not sure why this isn't the default to be honest.
That said, if you're developing software you should probably be running without any addons like uBlock enabled to prevent surprises in production for your non-uBlock users. Besides that, you can't get HTTPS for these domains (without the mess of a custom CA and even then you'll run into CT issues) so development doesn't even reflect real life deployments. Secure origins matter!
Lastly, you can't be sure any of these domains won't eventually resolve to a real IP address somewhere down the line, unless you own them. They're very useful but also very out of your control and that makes them a potential security risk.
The workaround should be obvious: add an entry to your hosts file (using either a TLD you own or the proper reserved TLDs (.test, .example, .localhost, .invalid, .home.arpa, and maybe .local though that can conflict with mDNS).
If you're using Chrome, you can probably use .localhost already, as it resolves those to your local domains for you. Still, adding a *.localhost to your hosts file will ensure that things actually work as intended.
Re: Document reasoning to block DNS to 127.0.0.1
#9This is the explanation given by the person who committed this change: > 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'…
[deleted]