Bugzilla

We are about to experiment with "shimming" resources blocked by tracking protection, so that rather than them being blocked outright, a stand-in version of the resource can be loaded by Firefox instead. This would help to resolve cases such as:
- behaving as though a blocked script still loaded, even if it's blank, so its onerror is not called (which breaks some pages).
- providing stand-in stubs for window objects/APIs which a blocked script provides, and which some sites rely on to load or behave properly (even if they are no-op stubs).
- providing a mechanism by which a stub/stand-in may tell tracking protection to unblock the resource (and other required ones), so that if a user opts into un-blocking it. that way, the stub may re-load the resource so the user may continue accessing the resources, without having to refresh the page.

While the initial version of the experiment can already un-block resources by altering the relevant `about:config` preferences, they are comma-separated string fields, and permanent. This is not only error-prone to manage, it also requires that the addon "take over" for tracking protection for any whitelisted resources, for as long as necessary, before resetting the preferences.

It would be safer if we had cleaner platform support for un-blocking a list of resources/URL patterns for a given eTLD+1, for a given duration (the current user navigation, their current session, or permanently). It would be nice if these patterns could match what WebExtensions use, perhaps by simply using MatchPattern syntax.

In addition to such an API, it would also be nice if the shimming could be handed off to the platform as well, since right now the webcompat addon (which is where our experiment will run) must start up before it can do any shimming. As this can happen after session restore, users may get an inconsistent experience if they restart Firefox. This may also help reduce any UI work we wish to do for users to be able to see and manage which shims are active at a given time.

In bug 1637329 we are about to experiment with "shimming" resources blocked by tracking protection, so that rather than them being blocked outright, a stand-in version of the resource can be loaded by Firefox instead. This would allow us to (for instance) shim Facebook's SDK, detect when the user attempts to log in, and only whitelist the relevant (potentially tracking) network requests at that point.

It would be ideal to have a Necko API which can detect if a given URL is being accessed, wait for an addon-style content script to load in its place, and then act as though the original script loaded. This would allow that content script to set up the window object as appropriate (adding a mock/stub object similar to what the original script provides, like `window.FB`), while also allowing it to call other privileged APIs in a sandbox, without risking the page being able to call those APIs as well. The original request would never be sent at all; no redirects/etc. It would simply behave as though it was an empty script which successfully loaded.

For instance, an API such as this would help:

`browser.network.overrideResponse(urls_to_shim, shim_id, shim_source_url)`

Where:
- `urls_to_shim` would be a set/array of standard [web extension match-patterns](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns)
- `shim_id` would be a unique string identifier for the shim (a GUID or addon-keyed ID)
- `shim_source_url` could be a `resource://` or `web-extension://` URL, or just plain text.

By registering shims this way, they can begin applying right away as Firefox starts up. This is important as the addon in bug 1637329 may not actually start before session restore kicks in.

Note that we would also require an analogous `browser.network.cancelOverrideResponse(shim_id)` API, as they may become obsolete over time, and users may also wish to opt out of a given shim.

Additionally, if performance is an issue it may also be a good idea to have an additional `hosts` parameter to restrict the shim so that it only runs for a specific set of TLDs (similar to the `hosts` parameter suggested in bug 1637371).

Having these as chrome-only JS rather than full-blown web extension APIs should also suffice, as long as web extension experiments can access them.

In bug 1637329 we are about to experiment with "shimming" resources blocked by tracking protection, so that rather than them being blocked outright, a stand-in version of the resource can be loaded by Firefox instead. This would allow us to (for instance) shim Facebook's SDK, detect when the user attempts to log in, and only whitelist the relevant (potentially tracking) network requests at that point.

It would be ideal to have a Necko API which can detect if a given URL is being accessed, wait for an addon-style content script to load in its place, and then act as though the original script loaded. This would allow that content script to set up the window object as appropriate (adding a mock/stub object similar to what the original script provides, like `window.FB`), while also allowing it to call other privileged APIs in a sandbox, without risking the page being able to call those APIs as well. The original request would never be sent at all; no redirects/etc. It would simply behave as though it was an empty script which successfully loaded.

For instance, an API such as this would help:

`browser.network.overrideResponse(urls_to_shim, shim_id, shim_source_url)`

Where:
- `urls_to_shim` would be a set/array of standard [web extension match-patterns](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Match_patterns)
- `shim_id` would be a unique string identifier for the shim (a GUID or addon-keyed ID)
- `shim_source_url` could be a `resource://` or `web-extension://` URL, or just plain text.

By registering shims this way, they can begin applying right away as Firefox starts up. This is important as the addon in bug 1637329 may not actually start before session restore kicks in.

Note that we would also require an analogous `browser.network.cancelOverrideResponse(shim_id)` API, as they may become obsolete over time, and users may also wish to opt out of a given shim.

Additionally, if performance is an issue it may also be a good idea to have an additional `hosts` parameter to restrict the shim so that it only runs for a specific set of TLDs (similar to the `hosts` parameter suggested in bug 1637371).

Having these as chrome-only JS rather than full-blown web extension APIs should also suffice, as long as web extension experiments can access them.

It's also worth noting that other components may wish to override requests at some point; the devtools may wish to implement an equivalent to Chrome's "local overrides", for instance. As such it may be worth getting others' input here.