Privacy Badger considers dev.to a tracker

[sztomi]

Before creating a bug report, try disabling browser extensions to see if the bug is still present.

^ This report is specifically about compatibility with a popular privacy extension, so I'm skipping this step.

Describe the bug

Privacy Badger is a popular set-and-forget privacy extension for Google Chrome and Firefox. It differs from other blockers in that there is no fixed blacklisting of trackers. The extension monitors websites for tracking behavior and blocks them based on what it observed.

dev.to happens to be detected as a tracker by Privacy Badger.

Usually the site works normally despite the blocking, but there is some broken behavior, too (see below).

To Reproduce
Steps to reproduce the behavior:

1. Install Privacy Badger
2. Browse dev.to for a while, until the extension changes the state for dev.to

To trigger the broken behavior when the blocking is active:

1. Visit an article while the blocking is active, e.g. https://dev.to/uf4no/my-kubuntu-osx-look-alike-desktop-setup-219g (I just verified the bahavior with this one, but probably any will work)
2. Click on the first image
3. Click on the back button
4. The "You are not connected to the Internet" page will be triggered
5. Refreshing the page keeps the not connected state
6. The only way to escape that is to copy the address and navigate to it in a new tab.

Expected behavior

I'm guessing this is a false positive by Privacy Badger (although I'm not familiar with the business model of the site, but from what I've seen it's not based on tracking the users). The solution is either to figure out what causes this detection and either or remove that behaviour, or work with Privacy Badger devs to fix it on their side.

If it's not a false positive, then dev.to either:

• should consider not tracking its users
• should work properly with trackers blocked

Screenshots

Desktop (please complete the following information):

• OS: Linux (but observed on other platforms)
• Browser: Firefox
• Version: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Additional context

https://www.eff.org/privacybadger/faq#I-found-a-bug!-What-do-I-do-now
https://github.com/EFForg/privacybadger

[abraham]

I couldn't reproduce this in Chrome.

[sztomi]

You can emulate the behavior if you set dev.to to manual blocking (it does take some time for PB to kick its autodetection).

[Link2Twenty]

Is it the default no connection page or the dev.to one?

I've just tried to replicate in Firefox but can't

---

If I manually block dev.to the service worker tells me it can't reach the domain. But if it's blocking the whole domain that makes sense.

dev.to is detected as potentially tracking the user but does not autoblock.

Green means there's a third party domain, but it hasn't yet been observed tracking you across multiple sites, so it might be unobjectionable. When you first install Privacy Badger every domain will be in this green state but as you browse, domains will quickly be classified as trackers.

It could be seeing the service worker being installed I suppose but that doesn't track anything.

[Zhao-Andy]

FWIW I couldn't reproduce this on Chrome and Firefox Developer Edition.

As @Link2Twenty mentioned, it might be related to service workers. We had a previous issue (#128) before where Privacy Badger had issues with service workers in general. I think they may have patched it, but it's been a while so I'm not sure.

Related issues:

• Firefox tab switch results in offline page when online #456
• Breaks ServiceWorkers in Firefox EFForg/privacybadger#1144

[sztomi]

Happy to provide more info or a screenrecording if you have issues with reproducing.

[ghostwords]

Yep, this is a Firefox-specific Service Workers bug: EFForg/privacybadger#1144 (comment). Reproducing it is a bit tricky as it requires you to "warm up" the worker. You can see https://bugzilla.mozilla.org/show_bug.cgi?id=1499523 for more information.

We haven't patched it yet in Privacy Badger but hope to soon as it affects all sites that use Service Workers.

[jessleenyc]

Thanks everyone. Looks like this is out of our hands so I'm going to close this issue.