@pde @cooperq @cowlicks So this was a Privacy Badger bug! Header names are case-insensitive, and cookie tracking detection code wasn't normalizing header names: f0a0fb9. Meaning Privacy Badger doesn't detect cookie tracking whenever the Cookie/Set-Cookie header is lowercase, which seems to happen consistently for this test in Firefox.

TODOs:

• Add unit test to cover this bug: 8112fa6
• Check why the test_cookie_tracker_detection test was passing in Chrome. Answer: Chrome capitalizes HTTP header names, Firefox lowercases.
• Clarify scope of breakage: It appears that Privacy Badger doesn't learn from cookie tracking in Firefox. Tested with the release-2017.1.26.1 tag in a new profile on Firefox 52.

Yikes! It would be good to understand how strict browsers are with accepting Set-Cookie headers. And if browsers always send cookies with a Cookie header. Could we be missing header names with whitespace in them? Or headers using an em dash instead of a normal dash like Set–Cookie. Ideally we'd have an internal browser function to validate this since diverging from its behavior could lead to some XSS or header injection.

Apparently http header field names are supposed to be case-insensitive. https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

It seems like header handling changed in Firefox somewhere between versions 52.0a2 and 52.0.1. A fresh install of Privacy Badger from AMO starts blocking after three newspaper sites on 52.0a2, but not on 52.0.1.

Note that you have to manually clear Badger's storage if you reuse the profile, as uninstalling Firefox extensions doesn't perform proper cleanup. Might be easier to use a new profile for each test.