@Shiz, you can import the static (ABP) rules in the My Filters tab and the dynamic (uBO) rules in the My Rules tab,
Remember you have to replace the rules
* nl * nooop
* uk * noop
For the country codes of the languages you speak, e.g. for Italian
* it * noop
* de * noop
* at * noop
* ch * noop
The problem that Manifest V.3 poses for these "smart" adblockers is made clear in the link from my Post #13 above. I've italicized a couple of salient points:Some time ago an academic study showed that adblockers with around 3K rules (Ghostery, Disconnect and Privacy Badger) did as good on the Alexa Top 100.000 as adblockers with over 100.000K rules (uBlockOriging, AdblockPlus and Adblock).
|An overview of the Manifest V3 proposal's impact upon Privacy Badger|
Privacy Badger is a browser extension that automatically learns to block invisible trackers.
The Manifest V3 proposal thoroughly breaks this description. It appears that Privacy Badger will no longer be able to dynamically learn to block trackers, report what it blocked on a page, block cookies from being set or sent, strip referrer headers, nor properly support EFF's Do Not Track policy.
If you remove what makes Privacy Badger unique, replacing it with basic list-based blocking, what are you left with?
Replacing persistent background pages with ServiceWorkers
A non-persistent event-driven background page does not work well for extensions that need to keep ephemeral state.
Restricting origin access / Manifest Host Permission Specification
Making users confirm extension access (host_permissions) does not seem to make sense for general-purpose content blocking (adblocker/privacy/security) extensions. Outside of edge cases (for example, a Facebook.com-specific extension), content blockers need access across all URLs. Redundantly prompting users for permission to run these scripts (on top of the existing notification users see when initially installing Privacy Badger) will be unhelpful and confusing.
As Chrome extension docs for permissions state:
Dynamic Content Scripts
It would be great to finally have dynamic, before-anything-else injection of content scripts (478183 - chromium - An open-source project to help move the web forward. - Monorail). However, as per the host_permissions note above, it doesn't make sense to make users have to re-confirm this access via permission dialogs.
Removing "blocking" (synchronous request/response interception) from webRequest will break core Privacy Badger functionality.
The declarativeNetRequest API is an entirely inadequate replacement as it supports onBeforeRequest blocking and redirection only (not header/body inspection or modification), and seems to support (a limited number of) hardcoded rules only.