Hacker News Reader

Comment by delroth | Hacker News Reader

What about MV3 requires going through the Chrome Web Store to update block lists? A quick look at the declarativeNetRequest docs (https://developer.chrome.com/docs/extensions/reference/decla...) shows that there are indeed static rulesets which need to be declared in the extension's manifest, but also dynamic rulesets which can be updated via JavaScript (and so presumably can be fetched and updated dynamically). I can't seem to find any specific limitation of dynamic rulesets vs. static rulesets.

View on HN

uBOL's FAQ entry: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...

Edit: Chrome docs on the matter explaining the limitations (from sibling mlyle) https://developer.chrome.com/docs/extensions/migrating/impro...

That doesn't really state if that's a self-imposed limitation or limitation of Mv3.

I've edited my comment to also include a link to the Chrome docs, but that FAQ entry also has the link to an issue in the webextensions repository indicating it's a limitation of MV3: https://github.com/w3c/webextensions/issues/112

But that issue has nothing to do with the question of whether the "filter lists" could be updated dynamically without store review. It's asking for a way of programatically triggering the update to the latest version of the extension in the store.

That feature request being fixed would do nothing to enable updates without store review. And likewise the feature for doing updates of the ruleset without a store review already exists but is not used by UBOL.

So the link doesn't actually support your claim of it being a limitation of MV3. The link is just irrelevant.

The FAQ hints at why UBOL doens't make use of that feature, but doesn't actually state it outright.

> So the link doesn't actually support your claim of it being a limitation of MV3.

From the issue: "In Manifest V3 remotely hosted code is no longer allowed."

Altought the parent was talking specifically about network requests, in which case you may be right and I missed it, but that's not the general problem. Blocking network requests is not sufficient for modern ad/tracking blocking and to be able to run effectively they need to inject scripts into the page, thus "remotely hosted code" is necessary, and the Chrome docs above says that it's not allowed.

The new complaint in the article was about dynamic updates not being possible. That is just demonstrably incorrect, and not countered in any way by the FAQ link.

But you're now trying to switch it to just a relitigation of switching to declarative blocking in general.

For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string[1], the content scripts must be part of the package.[2]

There is userScripts API which allows injecting code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API.[3] In Firefox, the documentation for this API has the following note[4]:

> When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts

* * *

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

[2] https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium...

[3] https://developer.chrome.com/docs/extensions/reference/userS... ("Availability Pending")

[4] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

That chrome.com page talks about not loading remote code and literally describes loading remote configuration as the correct fix:

> Alternative approaches are available, depending on your use case and the reason for remote hosting. This section describes approaches to consider.

> Configuration-driven features and logic

> Your extension loads and caches a remote configuration (for example a JSON file) at runtime. The cached configuration determines which features are enabled.

The uBlockOrigin FAQ seems to be mixing scripts to run as part of a page with declarative filter lists. I thought the whole point of Manifest V3 was to prevent extensions from snooping on online banking, email accounts, etc...

Nothing here seems to say that you couldn't update a declarative filter dynamically.

This was unclear to me as well.

I think the article is talking specifically about downloading and running scripts for working around a particular site dynamically, such as Youtube ad blockers.

That said, I don't know if this really is a technical block from e.g. adding a script tag to a YouTube page to pull in a third party resource. My impression was that it was blocking arbitrary scripts specifically within the extension context, and not in the browser context.

> I think the article is talking specifically about downloading and running scripts for working around a particular site dynamically

The article specifically mentions "filter lists" being subject to review time.

> All updates, even to benign things like a filtering list, will need to happen through full extension updates through the Chrome Web Store.

> Is a filtering list update, which is essentially just a list of websites, really something that needs to be limited by the "no remotely hosted code" policy?

> So since all filter list updates now need to go through the Chrome Web Store, how long does a review take?

https://developer.chrome.com/docs/extensions/migrating/impro...

Chrome explicitly recommends downloading remote configuration.

https://developer.chrome.com/docs/extensions/migrating/impro...

To me, this seems pretty clear: don't inject anything "executable" into a webpage except CSS.

It does look like you could maybe use a sandboxed iframe and ask it about page features and whether they should be blocked, and that this might be permitted.

CSS3 is turing complete: https://accodeing.com/blog/2015/css3-proven-to-be-turing-com...

Arithmetic + iteration is enough to be Turing complete.

CSS has arithmetic. It does not have iteration.

And even if it had full compute capabilities, the output is still just choosing CSS rules to apply.

Can you explain how the blog post/other results people have on CSS being turing complete are wrong?

Edit - would it be considered cheating to use: <meta http-equiv="refresh" content="10">

A far as I know you can still execute your code in any context, but the code can't be fetched, modified or built during runtime.

They can claim dynamic fetch is "phoning home" and a user privacy danger.

You're just making stuff up at this point with no evidence or source. If the intention was to forbid dynamic fetching of declarativeNetRequest filter lists, Google could also just... not have dynamic filter lists.

Google's playing the long EEE game. They do small things like this so people like you go around telling us it's not a big deal.

Will you say the same things 5 years from now? Google needs to be kicked out of consideration for web standards. They keep treating it like they own it.

Now there’s something Google Chrome would never do, phoning home.

Not even Brave would do that. Wait..

Is there anything in MV3 that enforces signed code? Could a separate client that fetches block lists itself and then side loads them be the answer?

Filter lists are data, not code.

Reply on news.ycombinator.com