*.ib.metapix.net blocks inkbunny.net private CDN

[GreenReaper]

Privacy Badger has been reported to block nl.ib.metapix.net. It would be nice if it didn't do that, as it breaks the site (most images/content), which is using it for every European visitor by default.

The ib.metapix.net subdomains are used on both dedicated servers and VPS to distribute access to content for furry art site inkbunny.net. The purpose of having a separate domain is to avoid the transfer of cookies with such requests, in part because the host may be a VPS in a country outside of Inkbunny's jurisdiction. Such caches are managed by Inkbunny staff and do not serve content for other websites.

Inkbunny does not log successful accesses to these caches; in fact it blocks accesses from sites which are not inkbunny,net or metapix.net domains via referer, to prevent bandwidth theft.

It's possible that visitors have tried to embed links on other websites, perhaps triggering Privacy Badger to think these subdomains are part of a public CDN, but such accesses should be refused.

[ghostwords]

I see what you mean about metapix.net being a non-tracking, single-site CDN. I can't figure out how to reproduce though ... It would help if we could ask whoever ran into this problem to run some debugging code in their Privacy Badger to help us figure out how this happened. Here are the instructions:

Could you run the following JavaScript code in your Privacy Badger's background page console, and send me what it prints out?

(function () {
  const STR = "metapix";
  console.log("**** ACTION_MAP for", STR);
  _.each(badger.storage.getBadgerStorageObject('action_map').getItemClones(), (obj, domain) => {
    if (domain.indexOf(STR) != -1) console.log(domain, JSON.stringify(obj, null, 2));
  });
  console.log("**** SNITCH_MAP for", STR);
  _.each(badger.storage.getBadgerStorageObject('snitch_map').getItemClones(), (sites, domain) => {
    if (domain.indexOf(STR) != -1) console.log(domain, JSON.stringify(sites, null, 2));
  });
}());

This should print the decisions your Badger reached for all "metapix" domains, and also the site domains Badger saw "metapix" domains perform tracking on.

To open Badger's background page console in your Chrome browser, visit "chrome://extensions", make sure "Developer mode" is checked (in the upper right), find the row for Privacy Badger, and click on the "background page" link in that row. Then, in the newly appeared window, make sure the "Console" tab is selected, click somewhere within the ">" prompt, paste the above JavaScript code, and press the Enter key.

[GreenReaper]

Furries use Firefox, because it has a fox. Is there an equivalent or similar method of determining the reason for the decision in this browser?

I cannot immediately reproduce the issue myself on Chrome or Firefox, so maybe it's to do with other sites the end-user accessed?

[GreenReaper]

OK, I figured out the method. For the benefit of that end-user:

• Open the URL about:debugging
• Enable add-on debugging and click Debug next to Privacy Badger
• Click the OK button on the popup warning about remote debugging.
• Enter the above script into the console after the >>

Personally I get:

**** ACTION_MAP for metapix 
nl.ib.metapix.net {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1493361237208
} 
**** SNITCH_MAP for metapix

[GreenReaper]

The end-user's result:

**** ACTION_MAP for metapix 
nl.ib.metapix.net {
  "userAction": "user_cookieblock",
  "dnt": false,
  "heuristicAction": "block",
  "nextUpdateTime": 1493104222984
} 
metapix.net {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "block",
  "nextUpdateTime": 1492879096021
} 
**** SNITCH_MAP for metapix 
metapix.net [
  "zafur.co.za",
  "businessinsider.de",
  "inkbunny.net"
]

zafur.co.za is a South African furry forum. It is possible that someone embedded a link to a file (which would not have loaded, but might have appeared to work if they had the image cached). I'm not sure about businessinsider.de, but possibly a remote avatar issue, or an image link in a comment?

[ghostwords]

Cool, thank you for tracking this down!

[ghostwords]

This bug should be fixed in Privacy Badger version 2017.6.13.1 (by #1403 and #1428). Please let me know if you run into it again with the new version.

[ghostwords]

This might have instead been caused by a different mis-attribution bug, what I describe in https://github.com/EFForg/privacybadger/pull/1642#issuecomment-328681731

[nicheAsQuiche]

Hello 👋 I own/ run MetaPix.art & metapix.io - I've recently had what looks like a bot drive some fake traffick - obviously to mess up analytics etc. this isn't related at all is it? I checked your site out @inkbunny but didn't see no issues so had a look then left aha!

[GreenReaper]

Hello 👋 I own/ run MetaPix.art & metapix.io - I've recently had what looks like a bot drive some fake traffick - obviously to mess up analytics etc. this isn't related at all is it?

I'm afraid not, this issue is about an old bug in some privacy software that misidentified our private CDN as a tracker, identified by one of our users (because this software blocked the site). We don't do any referer stuffing to promote the site.