Privacybadger: Are there any factors that could put something into an immediate red?

[jawz101]

Seems like there are a lot of issues reporting site breakage but, on the same note, are there characteristics which are blatant reasons to go ahead and forego the strike three policy?

I guess I worry that its purpose might get watered down with exceptions for the sake of whitelisting. Plus, we're creatures of habit so maybe the situation might not trigger a 3 strike policy.

Like has there ever been a web bugs that was benefit to me? Or sites which aggressively register service workers, try to do web sockets behind my back, using a bunch of web font junk, etc.

Like, if a single site tries to do a few things I immediately assume it's doing something screwy.

Also, does PB monitor 1st party as well as 3rd party? I also imagine things like CDN's and Google AMP are doing some tracking inherent in their design.

On that same note, I guess it'd be nice to have a wiki with a slightly nerdy logic diagram on how the heuristics work.

I could be talking out of my butt and this isn't really an issue.

[cowlicks]

Yes! There are definitely times we should do this, and I plan on doing it eventually. I'll explain why we can't right now, and how we'll get there.

Currently, the concept of "blocking" something in Privacy Badger is centered around origins. So when we block strongbad.com, all 3rd party requests from that origin are blocked. As well as subdomains of it, like foo.strongbad.com. So if I visit homestarunner.com, and it tries to load resources from strongbad.com, those requests will be blocked.

This makes sense when we think about cookie tracking, because cookies are scoped by origin. The problem arises when we see something like fingerprinting. Fingerprinting libraries are often loaded from a CDN. So we end up blocking the CDN by refusing to load things from cdn.com, we block the origin. But the cdn probably serves a lot of other useful stuff. So things break. We add the cdn to the yellowlist. The it gets to keep fingerprinting.

What we need is a more fined grained way to block things like this. Perhaps by URL. Perhaps by more context, like and 1st and 3rd party pair. This is described in #1527. However privacybadger's current architecture makes this hard. All rules are stored by the "basedomain" of the origin, in an Object. To fix this we'd need to track more than just the 'basedomain', so we'd need to make a big change to this data structure. I outline what we'd need in #1531

Currently, our priorities are fixing site bugs. So work on fixing this is postponed. If you'd like to pick it up some of this work, I'd be happy to break it into manageable chunks. We have public meetings every Monday and Thursday at 11:30 pst that you're welcome to join if you'd like to talk about this or anything else.

[jawz101]

I was starting to look into the meetings lol.

Well, you can close this as an issue unless you like having it for posterity.

I may not be the coder you're looking for but I'm certainly full of ignorant questions and ignorant opinions.

I basically block with impunity with NoScript, a few config changes, maybe uBo, and Decentraleyes and PB to catch what little gets through. I don't get near the breakage as terrorist96 but I think he must go to different sites than I do and my other layers kinda cause PB not to do as much. Still, it would be nice to scrap some add-ons but whenever I turn my other things off and let PB collect more I'm like "what's with all of this green stuff?" The names of ad and analytics companies just look too familiar to think they're not doing something that could preempt the current heuristic.

[jawz101]

... Like, I couldn't read the code of this add-on and understand it and that bugs me... but I think it'd make sense if I did know.

I do like the way you all work, regardless. Cowlicks, ghostwords, cooperq, and the other rock stars on the team. A very receptive group of folks.

[ghostwords]

This is good feedback, thanks!

For the short to medium term, I would like to focus on finding and fixing all sorts of general bugs, including but not limited to broken site issues ("site bugs"), that are some combination of being something we understand well, is relatively easy to fix, and impacts many Privacy Badger users.

As we address the most immediate user pain points, we gain a better understanding of what should follow, and, eventually, how exactly to go about pursuing it.