I'd like clarification on something. I've spent an hour or two trying to figure this out to no avail, so I suspect many other people might be wondering the same

I'd like clarification on something. I've spent an hour or two trying to figure this out to no avail, so I suspect many other people might be wondering the same thing I am. Examining the Manifest V3 changes more closely (https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/ https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o...), and comparing/contrasting to what uBlock Origin themselves say about it (https://support.ublock.org/hc/en-us/articles/11749958544275-Google-s-Manifest-V3-What-it-is-and-what-it-means-for-uBlock-Users- https://support.ublock.org/hc/en-us/articles/11749958544275-...), I can understand the cause of one of uBO's problems with V3... but not the other. The cause of "Allow List Limits" is clear: uBO Lite will be forced to use declarativeNetRequest; and declarativeNetRequest imposes limits on the size of the ruleset you can "declare". But I'm confused about uBO's point on "Ad Blocking Quality". It seems that Manifest V3 only restricts 1. the use of eval(), and 2. the loading of remote-origin scripts into the DOM and/or as service-worker modules. It doesn't restrict the use of remote-origin-loaded data files generally; which I would presume means that uBO would still be able to use its service-worker to periodically fetch and update its filter lists. Is there some part of the way uBO uses these filter lists, that requires arbitrary remote code execution (and for which the only true substitute is burning in the lists locally?) If so: why, exactly? (Not a rhetorical question; I'm not doubting that they do need it. I just can't figure out where the need comes from, and I'd like to know!) It might seem at first blush that the literal answer is this feature: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#scriptlet-injection https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#... ... but it actually isn't, as you don't write actual JS to be eval()ed in these rules, but rather just name a function that's already burned into the extension locally as part of its "scriptlet resource library". Is it instead, just the way that these rules get "baked down" into in-page logic? Does uBO compile the lists into a bunch of Javascript source-code, and then have the page evalScript() that code? And if that is the blocking issue — and I'm still not clear that it is — then wouldn't there be other workarounds for this? For example, sticking the generated JS code into a data: URL and then dropping it into the page as a <script> tag. Or even, at worst, swapping out feeding the page "JS source code", for feeding the page a (static!) interpreter, and then having that interpreter receive instructions as regular ol' data from the uBO service-worker? (Maybe that'd violate uBO's performance goals, I suppose? But it wouldn't have to do it on every page; only on pages that it knows from the ruleset can't be blocked entirely declaratively.)