Don't display a domain that is already blocked by other extensions

[gloomy-ghost]

Conflicting with other extension creates confusion for users, such as this comment.

On Chrome, there is an onErrorOccurred event when a request is blocked by other extension, so we can stop displaying a domain when it is already blocked.
https://developer.chrome.com/extensions/webRequest#conflict_resolution

EDIT:
Firefox supports this as well, https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onErrorOccurred

[cowlicks]

This would probably also resolve the occasional warnings we see on the extension page, which would be nice.

[gloomy-ghost]

A problem is that we currently don't store the exact URL of a request, so we can't detect weather a domain is blocked fully or partially. My thought is to record the count of logThirdPartyOriginOnTab being called and check if the same amount of onErrorOccurred events is received. Would this be ok?

[gloomy-ghost]

Another thought: There are several ways to deal with the domains that are blocked by other extensions.

• Simply don't display them
• List them as blocked (although they are not blocked by PB)
• List them in a separated category, such as "blocked by other extensions"

Which one is better?

[ghostwords]

resolve the occasional warnings

If I understand correctly, this involves registering another listener, chrome.webRequest.onErrorOccurred. Existing request-blocking listeners would continue operating as before; I don't see how we would get notified in time to avoid trying to modify a request that will get modified by a different extension.

[ghostwords]

Seems like not displaying domains blocked by other extensions is a good start.

We could probably use the details object onErrorOccurred listeners receive to match errors to our own request-modification activity.

However, I am concerned about the additional performance overhead required to do this, and also about whatever gotchas we might run into if we tried to do this.

For example, onErrorOccurred is fired when "a request could not be processed successfully", which includes but is presumably not limited to other extensions modifying the same request. What are the other scenarios that trigger it, and would they be a problem?

If you are interested, you could try a quick prototype implementation to see how far we can get given existing WebExtensions APIs. I feel like we need more information at this point.

[ghostwords]

Also, do any other request modifying extensions use onErrorOccurred?

[cowlicks]

I misunderstood the api for this. I thought we would be able to access errors with chrome.runtime.lastError. I do see some benefit to adding this to the UI, however with our current architecture, I think this would be difficult because the way we represent origins is fairly static and unable to listen for changes that don't come from storage.

[cowlicks]

I have been thinking about moving toward a more event driven model for origins so this has been on my mind. And I plan on generally moving in that direction to test it out.

[mijiturka]

If this feature is implemented, personally I would like to still be able to see the domains, even if they're marked as blocked by another extension. I use PrivacyBadger for information quite often, I think it's one of its best features that it shows me which sites go overboard with tracking, and which domains' services I should potentially be suspicious about.

[ghostwords]

chrome.webRequest.onActionIgnored is coming in Chrome 70: EFForg/https-everywhere#14961 (comment). Chrome 70 will also stop notifying users of extension conflicts. We may want to listen to these events and log the conflicts so that we can get this information when investigating bug reports. Are there conflict situations where it makes sense for Privacy Badger to notify the user directly?

[ghostwords]

The original reason (Chrome's scary extension conflict warnings) for this request is gone. There doesn't seem to be enough of a case to continue at this point.