Default to disable privacy badger when domain is localhost or 127.0.0.1

[irdan]

I just ran into an issue during development on an unrelated project that was actually just privacy badger blocking requests to the fqdn of the host I was port forwarding. On first glance it doesn't seem like a crazy idea to trust localhost or 127.0.0.1 to not maliciously track you.

If you agree this change should be put in place, I would be happy to submit a PR.

[cooperq]

Do you mean that privacy badger should not run when localhost is in the url bar, or localhost as a third-party should never be marked as tracking?

[ghostwords]

How should this work?

• When on a localhost/127.0.0.1/*.localhost page, don't learn anything new? (Could expand what incognito.learningEnabled() handles.)
• What about when you have a localhost-served third-party resource? I'm not clear on what this situation looks like. When would Privacy Badger see this resource on three separate first-party domains (sites) and learn to block it?

[bcyphers]

When on a localhost/127.0.0.1/*.localhost page, don't learn anything new?

Yeah, I think this is the right approach -- this would almost always be someone testing out a development version of a site, so (a) they should already know and control what trackers are on the page, and (b) the snitch map entries for their page will be useless for debugging later.

What about when you have a localhost-served third-party resource?

I can imagine this happening, again, in a development scenario. Maybe. I don't think there's any reason to add a localhost-served tracker to a snitch map, since the user should have full control of what that tracker does anyway.

[cupcakearmy]

Definetely need this. Happens to me a lot. For now you can set localhost es an disabled site in the settings