[jeroenhd]

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.

[oefrha]

> you can't get HTTPS for these domains

What are you talking about? Certificate insurance and DNS A/AAAA records are entirely decoupled. Use the ACME dns-01 challenge to get a cert for domains resolving to anything, including 127.0.0.1 or ::1. Alternatively you can even use http-01 or other challenges to get a wildcard cert, with subdomains pointing to localhost. I use Lets Encrypt certs for localhost and LAN every day.

Edit: a little more precision.

[jeroenhd]

Sure you can get a certificate for those domains, but not the domains you don't own. If I can get a cert for localho.st, someone made a huge mistake.

You can set up a localhost redirect on your own domain no problem, and you can even use a local DNS server to make sure nobody can abuse your localhost redirect so your domain doesn't get filtered out by tools like these.

However, I assume someone using fbi.com because it happens to redirect to localhost doesn't own a domain (or can't be bothered to set up a redirect of their own).

[xurizaemon]

For at least one of these tools / domains, local SSL is available. Details here: https://docs.lando.dev/core/v3/security.html

[jraph]

> 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 breaks 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. I definitely prefer having it enabled while developing.

> 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

[SahAssar]

> 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)

Of course you can, you just cant use HTTP validation for it. Use DNS validation and it works fine.

[jeroenhd]

Not if you don't control the DNS. I don't know who controls fbi.com but I sure can't get a trusted certificate for it

[SahAssar]

That was not the point you made in the original post. You said

> 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!

So you can absolutely make development match deployments.

[hnbear]

I thought about the cert thing here too.

I own a domain and internally use local.domain.com for all internal sites. Wildcard and specific names.

I can generate certs using ACME/LetsEncrypt.

So, everything, including test sites could be on that domain.

For reference, I use PiHole and OpnSense, and internally machines in DHCP and static IPs get local.mydomain.com resolution too.

[jeroenhd]

You can generate valid certificates for the domains you own and make the DNS point at anything you like. It's quite a pain for a dev setup (LE certificates only lasting three months, so long enough to forget about your setup but short enough that you'll need to keep running it).

In this specific case, it's about, a bunch of generic domains set up by other people.

In your pihole example the situation would be even better because you don't need to publish A records for the domains anywhere. That means nobody can abuse your domain for fingerprinting workarounds but you still maintain complete control.

[hnbear]

Yeah, it definitely introduces friction and setup cost.

OpnSense has an ACME plug-in to auto-renew, and can trigger jobs. In this case I have it renew and push certs to servers so they’re always renewed.