Our great sponsors
-
easylist
EasyList filter subscription (EasyList, EasyPrivacy, EasyList Cookie, Fanboy's Social/Annoyances/Notifications Blocking List)
-
mkcert
A simple zero-config tool to make locally trusted development certificates with any names you'd like.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
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.
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.
> 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.
It seems to me there's a higher risk that uBlock blocks something and break something than uBlock making something work that wouldn't for people not having it. I once had a filter block something called /share/ or share.js, fortunately I noticed during the development.
> 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)
Indeed. I recently had to do this and found mkcert [1] which makes it very easy to do. But it's overkill for most situations.
[1] https://github.com/FiloSottile/mkcert