Closed Bug 1637371 Opened 5 years ago Closed 4 years ago

Add JS-accessible platform API to avoid blocking resources with tracking protection

Categories

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

enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: twisniewski, Unassigned)

References

Details

Right now, the only practical way to achieve this (say for bug 1637329) is to manually manage the string prefs in about:config (urlclassifier.trackingSkipURLs and urlclassifier.features.socialtracking.skipURLs). This is of course very fragile, and also requires "taking over" the content-blocking of the urls if they are only meant to be whitelisted in some circumstances.

Ideally, a web-extension API along these lines would be preferable:

browser.trackingProtection.whitelist(urls, hosts, duration)

Where:

  • urls would be a set/array of standard web extension match-patterns
  • hosts (optional) would key the whitelisting only for a certain set of hosts
    • this keys against the hostname of the top-level frame, not of the frame making the request (consider third-party login popups)
    • support for wildcards like *.facebook.com or www.google.* would be very helpful
    • an ability to specify hosts as not being whitelisted would also be very helpful (not_hosts, etc)
  • duration could be one of:
    • for the current browsing session only (the default).
    • only on one tab until the user navigates away (perhaps by passing in a tabId).
    • permanently (on the user's profile, in case users wish a specific whtielisting to be permanent)

Another useful parameter to consider would be which features to whitelist for (social tracking, regular tracking, fingerprinting, etc). This could allow us to manage quick exceptions for specific sites (for the sake of webcompat) more easily.

Initially it would suffice to have such an API accessible to JS chrome, and only with the urls parameter. But since the addon in bug 1637329 would need to manage the hosts and duration parameters itself in that case, a matching API to dewhitelist(urls) would be required as well.

Additionally, if several addons/features wish to use this API, they may clash when trying to dewhitelist a URL, so it would be good to key the call on a GUID or feature name if it's a chrome-only API (or the addon's ID, if it's an addon calling the API).

See Also: → 1637329
Depends on: 1639718
Severity: -- → N/A
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.