1635997 - Add JS-accessible platform API to help with shimming network requests blocked by tracking protection

Status: RESOLVED WONTFIX

(Core :: Privacy: Anti-Tracking, enhancement, P3)

Description

[Thomas Wisniewski [:twisniewski]]

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
• 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.

Comment 1

[Johann Hofmann [:johannh]]

I'm a bit worried that already having the skip lists and the tracking protection exception, adding another separate mechanism to unblock things might introduce a lot of complexity in managing the overrides in the end. Assuming this level of detail in unblocking is really needed (which I haven't looked at in detail but will trust your judgement) it would be great if we could consider integrating it with the existing mechanism.

Comment 2

[Thomas Wisniewski [:twisniewski]]

I've updated the original comment and the bug's description, as I've split this bug up alongside bug 1637371 for each individual API being requested.

Comment 3

[Thomas Wisniewski [:twisniewski]]

Possibly related: https://bugzilla.mozilla.org/show_bug.cgi?id=1552326

Comment 4

[Thomas Wisniewski [:twisniewski]]

Given my discussions with :robwu while developing the current version of ETP shims, we aren't likely to want an extra API like this, as opposed to just improving the solution we already have (using webRequest APIs to override network requests).