Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Default to disable privacy badger when domain is localhost or 127.0.0.1 #817

Open
irdan opened this issue Apr 26, 2016 · 4 comments · May be fixed by #2666
Open

Default to disable privacy badger when domain is localhost or 127.0.0.1 #817

irdan opened this issue Apr 26, 2016 · 4 comments · May be fixed by #2666
Assignees
@ablanathtanalba
Labels
enhancement help wanted heuristic Badger's core learning-what-to-block functionality

Comments

@irdan
Copy link

irdan commented Apr 26, 2016

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
Copy link
Contributor

cooperq commented Apr 27, 2016

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 ghostwords added the heuristic Badger's core learning-what-to-block functionality label Apr 18, 2017
@ghostwords ghostwords mentioned this issue Oct 3, 2018
Closed
@ghostwords
Copy link
Member

ghostwords commented Oct 3, 2018 •
edited

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
Copy link
Contributor

bcyphers commented Oct 3, 2018 •
edited

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.

@ghostwords ghostwords mentioned this issue Feb 26, 2020
Open
@ghostwords ghostwords mentioned this issue Jul 2, 2020
Closed
@ghostwords ghostwords mentioned this issue Jul 31, 2020
Merged
@ablanathtanalba ablanathtanalba self-assigned this Aug 11, 2020
@ablanathtanalba ablanathtanalba linked a pull request Aug 13, 2020 that will close this issue
Open
@cupcakearmy
Copy link

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

@ghostwords ghostwords mentioned this issue Mar 23, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ablanathtanalba ablanathtanalba

Labels
enhancement help wanted heuristic Badger's core learning-what-to-block functionality
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Disable on localhosts EFForg/privacybadger
6 participants
@cooperq @ghostwords @irdan @bcyphers @cupcakearmy @ablanathtanalba