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.