I found that there's a confusion about the trusted scriptlet conversion to uBO format.
In FiltersCompiler, this code explicitly skips trusted scriptlets when converting to uBO:
|
// https://github.com/AdguardTeam/Scriptlets#trusted-scriptlets-restriction |
|
// does not work in other blockers |
|
const message = `Trusted scriptlets should not be converted to uBO syntax. Rule: "${rule}"`; |
|
logger.warn(message); |
|
modified.push(''); |
|
return; |
At the same time, uBO’s Resources Library documents trusted scriptlets (for example trusted-click-element, trusted-set-session-storage-item, etc.), and they mention the Adguard website, which indicates the correspondence:
So I’m trying to understand the rationale in FiltersCompiler. Is this an intentional policy decision (e.g., trust-source/security model mismatch) rather than a technical capability mismatch? Or is it just outdated information?
If it's the latter case, would it make sense add conversion support for trusted scriptlets?
I found that there's a confusion about the trusted scriptlet conversion to uBO format.
In
FiltersCompiler, this code explicitly skips trusted scriptlets when converting to uBO:FiltersCompiler/src/main/converter.js
Lines 131 to 136 in 4ab18cd
At the same time, uBO’s Resources Library documents trusted scriptlets (for example
trusted-click-element,trusted-set-session-storage-item, etc.), and they mention the Adguard website, which indicates the correspondence:So I’m trying to understand the rationale in
FiltersCompiler. Is this an intentional policy decision (e.g., trust-source/security model mismatch) rather than a technical capability mismatch? Or is it just outdated information?If it's the latter case, would it make sense add conversion support for trusted scriptlets?