migrate to manifest v3

[ablanathtanalba]

Roadmap to Migrating to Manifest V3

this document will be deleted in a final commit before any changes get merged into master

This is very much a WIP.
It's a task list, a list of relevant resources, and potentially somewhere to bounce ideas about how Privacy Badger could evolve in a post MV3 context.
We know that much of the webRequest API changing to declarativeNetRequest will break core functionality of Privacy Badger. How could Privacy Badger remain a useful and easy-to-use tool with mostly just observational capabilities in the Chrome browser?

Timeline

Links

• declarativeNetRequest API documentation
• Google group discussion about changing webRequest API
• chrome developer guide to migrating to v3
• chrome developer guide to migrating from Background Pages to Service Workers
• chrome design document (hasn't been updated in a while)
• chromium issue discussing MV3 implementation

Tasklist:

in manifest.json:

• change manifest_version from 2 to 3
• change permissions into host_permissions
• change background.scripts into background.service_worker
• change value in background.service_worker from an array to a string of the relative path to the root service worker
• change browser_action into action

in the JavaScript:

• replace all instances of chrome.browserAction with chrome.action
• replace all instances of chrome.webRequest with chrome.declarativeNetRequest
• migrate all chrome.extension.getBackgroundPage to other messaging contexts and/or background.service_worker scripts defined in the manifest

[ghostwords]

Two big issues I'm aware of (100% there are more that I don't yet know of):

• Injecting JavaScript into page context scope before-anything-else-happens is more broken than before. The current problem in MV2 is we don't have a way to synchronously provide configuration to before-anything-else page scripts. MV3 adds the problem of not being able to inject text or blobs into pages thanks to new Content Security Policy restrictions. So our current page script injection approach is broken. We may be able to work around via web_accessible_resources (requires more investigation; comes with increased fingerprintability concerns; may introduce enough injection delay to make it pointless).
• webRequest listeners go to sleep forever/never get reawakened after the MV3 Service Worker background page goes to sleep. This breaks webRequest-based learning capabilities (learning from cookie headers) of Privacy Badger.