Yellowlist api.infura.io

[jamespic]

Privacy Badger has a habit of redlisting api.infura.io, a blockchain-as-a-service API used by some Ethereum distributed applications, breaking the applications. Since the API is stateless, it works quite happily yellowlisted.

[ghostwords]

Why is the domain getting blocked in the first place though? Could you run the following script in your Badger's background page console and share what it prints out?

(function () {
  const STR = "infura.io";
  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));
  });
}());

To get to the background page console in Chrome, visit chrome://extensions, make sure "Developer mode" is checked, click on the "background page" link in Privacy Badger's row, and select the Console tab.

In Firefox, visit about:debugging, enable add-on debugging, click Debug next to Privacy Badger, click the OK button on the popup warning about remote debugging, and enter the above script into the console after the >>.

[jamespic]

**** ACTION_MAP for infura.io
VM263:5 form.infura.io {
  "dnt": false,
  "heuristicAction": "allow",
  "nextUpdateTime": 1522882350468,
  "userAction": ""
}
VM263:5 infura.io {
  "dnt": false,
  "heuristicAction": "block",
  "nextUpdateTime": 1523132354250,
  "userAction": ""
}
VM263:5 mainnet.infura.io {
  "dnt": false,
  "heuristicAction": "block",
  "nextUpdateTime": 1524171224418,
  "userAction": ""
}
VM263:5 api.infura.io {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1524235149771
}
VM263:7 **** SNITCH_MAP for infura.io
VM263:9 infura.io [
  "live.com",
  "infura-staging.now.sh",
  "parity.io"
]

[ghostwords]

Is this a case of session cookies (you being signed into the service) being sent along when fetching third-party resources provided by the same service?

If this is what it is, then a couple of suggestions:

• To improve website performance/security, the service should avoid having session cookies be associated with static resources/API endpoints (by configuring a dedicated static resource (sub)domain).

• If the service is able and willing to abide by the EFF Do Not Track policy's requirements on the affected domains (api.infura.io), posting the policy on each domain will tell Privacy Badger to always allow loading of resources from the domain.

[jamespic]

Those sound like suggestions for the operators of Infura (which doesn't include me - I'm just working on sites that call their API). The api.infura.io domain itself doesn't set cookies, and doesn't rely on them being set in order to work (although it's possible that cookies from other *.infura.io domains are being sent along - I'll double check).

Is there anything else I can do to help diagnose what's causing it to be blocked.

[ghostwords]

Yes, could you please check if your session cookies are being unnecessarily sent along with Infura API requests? If that's the case, we should get in touch with Infura to make the above suggestions.

[ghostwords]

You could check by visiting your cookie management screen (chrome://settings/siteData in Chrome) and seeing if you have any cookies or other data for "infura".