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)
urls_to_shim would be a set/array of standard web extension 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
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.