Firefox not unblocking subdomains of cookieblock list

[anonsubmitter]

Sample: http://www.hd-trailers.net/search?cx=partner-pub-0559071095567784%3Aaxv0su-iipx&cof=FORID%3A10&ie=ISO-8859-1&q=Mad+Max%3A+Fury+Road&sa=Search

Search for anything on http://www.hd-trailers.net/ and you'll notice that the search results page is blocked. Changing www.googleapis.com from being completely blocked (red) to just blocking cookies from the domain (yellow) fixes this.

[cooperq]

googleapis.com is already on the cookieblock list. So www.googleapis.com, as a subdomain, should also be cookie blocked. This is a bug.

[SwartzCr]

The problem seems to be in lib/cookieUtils.js while we've refactored cookie blocking to work with the cookieDb rather than the Firefox cookies, the function being called is canAccessCookies, which has spurious execution.

First if it gets called without a channel it uses the firefox cookie settings, then it sees if cookieDb has an entry for the origin, if it doesn't it once again falls back to Firefox cookie settings. Since none of these things check for rules for parent rules, subdomains of things with rules don't get checked

The proper workflow is likely to see if the 'location' has a rule, if it does then return that rule data, if not strip the first section of the domain out and check again. Repeat this until we get a rule or we're out of domain and then return false if no rule was generated.

@cooperq I'm curious if there's a reason you left all of this firefox rule code in there

[SwartzCr]

I'm also really confused about whether cookieUtils.canAccess is returning a boolean, it seems to have values like this constant: const _ALLOW = Ci.nsICookiePermission.ACCESS_ALLOW; and then is using that later in if statements

[SwartzCr]

okay 1) the problem is confirmed not to be in lib/cookieUtils.js 2) I can't reproduce this issue, as www.googleapis.com doesn't seem to be a source on hd-trailers.net

That said the function to look at would be _heuristicCookieBlocksRequest in lib/contentPolicy.js, and I will go look at that now

[SwartzCr]

I;m going to table this until I can reproduce

[SwartzCr]

I officially cannot reproduce this steps to fail to reproduce: 1) ensure that add-on debugging is enabled: https://developer.mozilla.org/en-US/Add-ons/Add-on_Debugger 2) open the addon debug console from the addon menu 3) get simple-storage, type: x =loader.modules['resource://gre/modules/commonjs/sdk/simple-storage.js'].exports.storage.preloads 4) do something like: x["doubleclick.net"] = "third-party" --- which will add it to the cookieblocklist 5) load up your favorite trackers (for this I used cnn.com, nyt.com, gawker.com, buzzfeed.com) 6) see that all subdomains of doubleclick.net, such as ad.doubleclick.net are now set to yellow and not blocked 7) wipe privacy badger and see that these domains are typically blocked when seen

[cooperq]

Interesting, I wonder what is happening in these strange cases then. We might have a race condition that could be fixed, I suspect that writing tests and refactoring is the real solution to this problem.

That said, I think we should write a test case for this to make sure it doesn't ever happen.

[cooperq]

I was able to reproduce this in #554, on http://kcundercover.wikia.com/wiki/Episode_Guide fonts.googleapis.com is being blocked. Definitely a bug.

[cooperq]

hmm, now I am unable to repro this again

[cooperq]

@nyuszika7h Is this still an ongoing problem for you? I am still unable to reproduce it and I would like to collect more details about your setup. Can you tell me what version of firefox and what OS you ahve? Can you also tell me the version of privacy badger you have and any other browser extensions you have installed?

[cooperq]

I am also officially unable to reproduce this. Though I have now written a test case in a5d93044d5279cd17576526f09f01416f81840ca I wonder if this is a bug that existed previously in privacy badger that is not present in new installs. Maybe I can reproduce by installing an old version of privacy badger and then browsing around for a while and then upgrading. @anonsubmitter @nyuszika7h it would be helpful if you could tell me what version of privacy badger you originally installed, what version you currently have and all of the pertinent details about your firefox installation. And any other browser extensions you might have installed.

[cooperq]

I tried installing an older version and upgrading to the new one but didn't have any luck with that approach. Waiting on more info from other bug reporters.

[anonsubmitter]

I have no idea what version of Privacy Badger I had originally installed. All other info is available here.

[cooperq]

at long last I can reproduce this, AND #551 (and all of anon submitters site bugs). The issue appears to happen when you have firefox set to not accept any cookies. Steps to reproduce:

1. Change cookie settings in firefox to never accept any cookies
2. Start browsing
3. ???
4. Profit!

[thrnz]

WRT reproducing #551, I have cookies enabled in Firefox (keep until they expire), however third party cookies are set to never accept. Would it still reproduce with these settings?

[cooperq]

Having now researched the bug I suspect that it would.

[cooperq]

Working on this issue in https://github.com/EFForg/privacybadgerfirefox/tree/issue_516

[jawz101]

Does this mean having stricter cookie settings in your browser cancels the purpose of PB? I always set my browser not to accept 3rd party cookies. Pardon my ignorance. Or should I regard PB as an alternate cookie mgmt engine and, if so, leave Firefox's cookie settings at default?

[ghost]

Sorry for the late response, and yes, I'm still having this issue. Windows 10, Firefox 40.0.3 (configured to block third-party cookies) and Privacy Badger 1.0.1.

[anonsubmitter]

Should I stop reporting site bugs until this is solved? I could maybe just save URLs of new fake site bugs in a .txt file or Google document and re-evaluate them after the bug has been isolated and fixed.

[cooperq]

Please do stop submitting until this is resolved! I think I will have a fix up in the next couple of days.

[anonsubmitter]

Ok.

[cooperq]

I think this should be fixed now with the last update. Closing for now.