Not a fan of EasyPrivacy. It seems to be run by trigger happy people with pretty limited understanding of the web.<p>They once blocked workers.dev (Cloudflare Workers) wholesale[1], resulting in a huge flood of issue reports for a few FOSS services of mine. Guess they've never heard of public suffixes.<p>This one appears to be someone reading about DNS rebinding attack somewhere, then pulling the trigger without understanding it. Or maybe I even overestimated them, DNS rebinding only came up as a justification very deep into the discussion.<p>To make matters worse, clients using these block lists have update frequencies all over the place, so you can never be sure when your stuff gets unborked for all your users even after they revert changes like this.<p>[1] <a href="https://github.com/easylist/easylist/commit/e4b0216">https://github.com/easylist/easylist/commit/e4b0216</a>
This is the explanation given by the person who committed this change:<p>> 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.<p>It makes no sense to me. Unless someone knows of a better reason, I'm of the opinion that this change should be reverted.
While I think that I somewhat agree with their reasoning, someone must also say that we are quickly in multicast territory here.<p>Should websites be allowed to resolve airprint or airdrop based devices, given the history of CSRF vulnerabilities in consumer routers? Probably not.<p>Devs seem to confuse that most humans are not developers, and therefore easylist's decision to do so has that kind of context.<p>The point of those lists is to block away access to local domains so a malicious website that got through the filters isn't able to pwn your whole network.<p>And if we are discussing whether or not websites should be allowed to access the local network, then you are probably someone who doesn't give a damn about securing those devices anyways.
I must be in the minority here thinking this move makes total sense.<p>Once I had to apply a firmware update to a device (don't remember what it was). I had to install some vendor's software but surprisingly the instructions said to then visit a public URL like fwupdate.vendorswebsite.com, which indeed applied the update to my physically connected device.<p>I dug into it and turns out the software launches a local web server listening on localhost which exposes an API that the website accesses over plain CORS HTTP to localhost. This web server talks to the device connected over USB.<p>This felt like an egregious breach of privacy--public websites should not be allowed to arbitrarily exchange data with locally-bound servers. Even though this was the intended design of the firmware update process, my browser really should not have let this occur by default without my explicit opt-in.
This is pretty unrealistic even given the maintainers example:<p>> 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.<p>That web server would need to be configured for CSRF and CORS of that specific domain as well. If this were an attacker then it wouldn't take long to seize that domain.<p>To fully extrapolate that, the server would only be accessible by the users machine. There's no implication of "third party access". Maybe if they were demanding the website to have a higher classification of verification for their certificate I'd understand, but frankly without an example of where and how this is a vector I'm skeptical.
Has this user’s GitHub account potentially been compromised?<p>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.
Do they only block 127.0.0.1? If this truly is a security improvement I would like to see an explanation why they don't block 127.0.0.0/8 instead.
Annoying, 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.<p>I'm not sure why this applies to first party browsing, though. In its current form (<a href="https://github.com/easylist/easylist/blob/master/easyprivacy/easyprivacy_thirdparty.txt#L2455">https://github.com/easylist/easylist/blob/master/easyprivacy...</a>) 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.<p>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!<p>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.<p>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).<p>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.
This is not the right way to block domains that resolve to local addresses even if that was something you desired to do.<p>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.
The issue might be more interesting to read: <a href="https://github.com/easylist/easylist/issues/16372">https://github.com/easylist/easylist/issues/16372</a>