fix: update autoconsent library to 12.x

[smalluban]

• The eval message is no longer sent to the background - execution of the scriptlets is done by the Autoconsent class in the content script by the library
• The library includes a source of the adblocker engine, even though we are not using it. The final size of the content script increased from 89kb to 528kb.
• From initial testing, the library went much slower in detecting and "clicking" on CMPs—it might be related to the fact that we disable cosmetics, and then those CMPs are not hidden (?).

[github-actions]

Builds for commit 7f979b4:

• ghostery-chromium-10.4.17-7f979b4
• ghostery-firefox-10.4.17-7f979b4

[muodov]

hey @smalluban, a few notes from the autoconsent side:

• in the next release (this week) we will make sure that the default Autoconsent bundle tree-shakes the adblocker library. So the bundle size should become smaller
• There were no changes to the eval behaviour: those messages should be sent to the background, unless isMainWorld is truthy (it is not by default). Could you elaborate on what you're seeing there?

[seia-soto]

Just like we disabled enableCosmeticRules before, I think it's good to set enableFilterList: false. Then we don't need to take care about change of default in the future. I think everything else is fine.

[smalluban]

@muodov It looks like you are right. However, I thought that for a simple reason - the build library contains all of the snippets and methods to execute them - mainWorldEval() - why? This is useless, as those snippets are never run by the content script, but because they are referenced by this method, the library contains all of them in the body...

Moreover, the snippets are not exported by the npm package, so we reference lib/eval-snippets.ts directly in the background, but with the update to 12.x our build system complains:

[commonjs--resolver] Missing "./lib/eval-snippets" specifier in "@duckduckgo/autoconsent" package

[smalluban]

I've found that referencing snippets is our "hack" - #1599 added by @chrmod some time ago.

@sammacbeth @chrmod We had a similar issue with CSP with injecting scriptlets. Can you provide snippets as a main export instead of passing them with a message from the content script? As we have changed that in the above PR?

[muodov]

@smalluban there is an option isMainWorld, which makes the content script execute snippets directly, without a round trip to the background. This is useful if the content script is injected in the main (not isolated) world, but it may be limited by page csp, depending on how you inject the script.

As for the imports, you can still import anything if you reference the package dir directly. That is, 'node_modules/@duckduckgo/autoconsent/...' instead of '@duckduckgo/autoconsent/...'

I hope it helps!

[smalluban]

@muodov I would like to avoid that hack at all, as your source might change at any time, or even it should not be distributed with the npm package in the first place.
Can you provide the main export, so that we can import it like this: import { snippets } from '@duckduckgo/autoconsent?

EDIT: this is already in the dist, but just as a variable var snippets = ... - so it is just about adding export ...

[muodov]

@smalluban it shouldn't be a problem to export snippets. Could you create an issue for this with a summary of your use case?

[smalluban]

@muodov duckduckgo/autoconsent#570

[github-actions]

Builds for commit e630856:

• ghostery-chromium-10.4.19-e630856
• ghostery-firefox-10.4.19-e630856