Incorrect detection of non-existent server tracking

[fpucore]

We have come to understand that the latest update to the Privacy Badger tool has now detected our central server (IP address 115.69.40.134) as tracking our users.

This is completely false and I can confirm there is absolutely no tracking software or mechanism of any kind used on any of the servers that we control and use.

[SwartzCr]

hmm can you confirm that it is not setting cookies or modifying localStorage?
If so, please give us the URL of this server, as well as three other domains where it might appear as a third party
One of two bugs might be happening with Privacy Badger, maybe

1. it is marking non-tracking domains as tracking, or
2. it is counting thing smultiple times from the same parent domain

[fpucore]

Website is www.freedompublishersunion.com.

Our central and main server uses IP address as stated in original post. The entire website runs off multiple servers, in a complicated manner which does not use a traditional form of DNS to operate and connect.

In addition to the main server, we also use IP addresses of:
31.170.160.111
31.170.160.81
31.170.160.83
31.170.164.116

[cooperq]

can you tell us any websites that might be including freedompublishersunion.com as a third party resource?

[fpucore]

None that I am aware of. I do know that one of our hosting companies adds the following Javascript string to our pages hosted on some servers. Whether this is triggering the alert with Privacy Badger, I have no idea. But the text string is as follows:
script type="text/javascript" src="http://stats.hosting24.com/count.php"

Full string here:
http://pastebin.com/Srh50j3U

[cooperq]

Privacy badger only ever blocks third party domains, so I need more details here. Can you tell me exactly what is happening to your users?

[fpucore]

I am not too sure what more details I can provide you with as you may have to be a little more specific of what you need. When I navigate to www.freedompublishersunion.com this is exactly the notification that I get from Privacy Badger:

I have switched Privacy Badger to Allow the domain, as you can see in the attached screenshot. The only server that we use that Privacy Badger seems to believe is tracking our users is the one located at 115.69.40.134. This is our core server and delivers access to probably 80-90% of the website.

[cooperq]

When I go to your website I get a message about it being down, not related to privacy badger. Is this happening for anyone else right now?

[fpucore]

Sorry, it is back online now.

[cooperq]

Interesting , your ip address doesn't get blocked for me, just the google fonts stuff. I think this probably happened because you have cookies from that IP due to being the administrator. It seems unlikely that it will show up as a tracker for your readers.

[fpucore]

I usually use Firefox as my default browser. I just tested this in Google Chrome and it does not block the aforementioned IP address.

Hopefully this narrows it down for you; that the problem is only when using Firefox+Privacy Badger.
Google Chrome+Privacy Badger works just fine.

[cooperq]

again, this is probably due to you getting cookies in firefox from being signed in as an administrator. I don't think this is likely to affect your readers unless you can provide specific examples.

[fpucore]

Ok I think I understand now. I have tested on machine with different IP addresses other than that of the server(s) and it seems to work just fine, without tracking detection.

Using Tor (for example), works fine with normal Privacy Badger behavior.

[fpucore]

As the developer, it's up to you where you go from here.

[mpalmer]

I'm getting (reports of) the same behaviour: the domains cdn-business.discourse.org and avatars.discourse.org are being blocked for a user running PB Firefox (version is reported as, "I don't know what version of privacy badger, but the addons page says last updated 4/21/2016, and no updates were found when I check."), but I'm not seeing any misbehaviour when using PB Chrome. Neither of those domains (should be) sending any cookies, and I've verified that they're not sending cookies to me for a couple of URLs I checked.

There are hundreds of domains for which these two domains would be third parties; the report originally came from https://community.letsencrypt.org, but https://community.infinite-flight.com/, http://forum.choiceofgames.com/, and http://commons.commondreams.org/ also reference those two domains. If you need more domains, just let me know. I've got plenty.

As an aside, it would be really helpful in cases like this if there was a "tell my why!" button that I could guide people to use when they reported these problems (or that I could use when PB blocks something). A straightforward "The cookie (xyz) looks dodgy af" style output would make it much easier to identify what's going on, from the user's perspective. If that hasn't already been reported as a feature request, and it has any chance of getting up, let me know and I'll open a new issue on it.

[ian-kelling]

I agree with @mpalmer, when privacy badger blocks a site, I get a control where I can unblock it, privacy badger gives me absolutely zero information about why I should or should not unblock that site, or in fact any site ever. Reading through the whole faq, the only thing it says is: "If you find domains that are under- or over-blocked, please file a bug on Github." How would I ever know if it's oberblock or underblocking a site? I have no idea. It's a horrible user experience. Same goes for "report this site is broken." Well, if a site won't work because it's got a bad implementation that won't work without tracking me, then it's not broken, it's appropriate blocked, so again, I have no idea when I should use that form.

[rugk]

Maybe open a new issue for "Badger, please tell me why?"?

[mpalmer]

@rugk before I did that, I wanted to get some indication of whether or not there was any hope of such a thing being implemented. No point spending time clogging up the issue tracker if it's already been considered and rejected for some reason.

[cooperq]

@mpalmer I would be open to such a feature given that it meets 2 requirements:

1. There must be a clean way to add this to the UI
2. There must be a way to meaningfully inform the user so that they can make a reasonable choice. Assume this user knows nothing about how web tracking works.

[mpalmer]

@cooperq, not sure why this was closed. I'll open a separate issue on the "tell me why this was blocked", but the originally reported issue still remains: a site which does not track anything, and which as far as I can tell does not look like it's tracking anything, is being blocked by Privacy Badger.

[cooperq]

Ah, this is because when privacy badger sees tracking on a domain it blocks the entire top level domain, including all subdomains. So for example avatars.discourse.org is not tracking but some other foo.discourse.org is tracking, privacy badger blocks *.discourse.org which blocks avatars.discourse.org even though it wasn't tracking. The reason for this is because if we just blocked the subdomain that was tracking a third party could use random subdomains and correlate the cookies on the back end. Does that make sense.

[mpalmer]

It makes sense as far as it goes. It would also explain why some users are seeing problems, while others aren't (presumably the users that are seeing problems have visited whatever subdomain is being marked as tracking). That raises the question, though: how do I go about figuring out which subdomain PB actually does think is tracking? We don't do any deliberate tracking on any Discourse subdomains, so it's not a matter of saying, "oh yeah, it's probably this one over here that's throwing up a supercookie".

[cooperq]

:) I'm sure that you don't! Unfortunately privacy badger doesn't keep a log of which domains specifically triggered tracking. One of the things that we look at is localstorage, is it possible that one of those domains is setting things in localstorage?

[mpalmer]

Discourse itself uses local storage, and we do run some Discourse sites under discourse.org (meta.discourse.org, try.discourse.org), but those sites shouldn't, under normal circumstances, be a "third party" for anyone else's site.

It's a pity no log is kept of which subdomains were the offenders. Is there a way (short of, presumably, uninstalling and reinstalling privacy badger itself) to "reset" a domain's status? That at least would allow us to rule out the possibility that some tracking that used to be on avatars (done without our knowledge by the CDN we used to use) has caused PB to get itself in a permanent knicker-twist. I don't see how it'd be working for me, and not for others, if that were the case, but I'm not one for thinking my assumptions are gospel.

[cooperq]

@mpalmer where is discourse actually broken? Can you show me an example? If it's never a third party then privacy badger shouldn't have any problem with it. Otherwise if privacy badger is breaking something on meta.discourse.org then, it's probably another domain that is the offender.

[mpalmer]

I've only had reports of the problem, I haven't been able to reproduce it myself -- which would normally be concerning, but based on your description of some of PB's internals, it's not unknown for a site to be blocked for some people but not others. The original reporter, @ian-kelling, has commented on this issue, so hopefully he'll be able to chime in with more details if you need them.

[cooperq]

So looking at that report it looks like a bug in privacy badger for sure, but one which I think is now fixed. I just looked at it and cdn-business.discourse.org is properly marked as having DNT. I think whatever this issue was it should be fixed now.

[JonathanDoughty]

Just sayin I got this this morning and tracked the discussion about the issue this far. Starting from https://community.letsencrypt.org/; using Firefox 49.0.1, Privacy Badger 1.8.1, and HTTPS Everywhere 5.2.5 (if that matters.) I have PB reporting avatars.discourse.org is blocked and I only got that far by letting cdn-business.discourse.org set cookies. The UX for this remains sad and whatever issue this is remains open for me.

[mpalmer]

Just an FYI, we're seeing reports of this again: https://twitter.com/flobin/status/816726049748910080 Again, I'm not able to reproduce the problem myself.

[riking]

Sample request for Discourse problem:

kane@local:~$ curl -I "https://cdn-enterprise.discourse.org/mcneel/site_customizations/7e202ef2-56d7-47d5-98d8-a9c8d15e57dd.css?target=desktop&v=20e05001ac856258fe9137fd0ad37318&__ws=discourse.mcneel.com"
HTTP/1.1 200 OK
Server: keycdn-engine
Date: Thu, 05 Jan 2017 01:34:24 GMT
Content-Type: text/css; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Discourse-Route: site_customizations/show
Last-Modified: Thu, 15 Dec 2016 06:56:53 GMT
Cache-Control: max-age=31557600, public
X-Request-Id: e69cb6cb-bbe0-45ed-8145-8fa1b1c01285
X-Runtime: 0.021647
X-UA-Compatible: IE=edge
Discourse-Proxy-ID: app-router-tiehunter06
X-Cache: HIT
X-Edge-Location: ussj

The v is a hash of a file version number.

[cooperq]

Could I trouble you to re-open this issue on https://github.com/EFForg/privacybadger ?
This repo is now deprecated and we are no longer following up with issues against this code base.

[mpalmer]

Done. Let's continue over there.