5 ms·

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/d

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/declarativeNetRequest/ 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.

fgoesbrrr 3y ago
They can claim dynamic fetch is "phoning home" and a user privacy danger.
- delroth 3y ago
  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.
  - zlg_codes 3y ago
    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.
- tinus_hn 3y ago
  Now there’s something Google Chrome would never do, phoning home.
  - Dah00n 3y ago
    Not even Brave would do that. Wait..
dwaite 3y ago
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.
- delroth 3y ago
  > 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?
  - charcircuit 3y ago
    https://developer.chrome.com/docs/extensions/migrating/improve-security/#configuration-drive https://developer.chrome.com/docs/extensions/migrating/impro... Chrome explicitly recommends downloading remote configuration.
- mlyle 3y ago
  https://developer.chrome.com/docs/extensions/migrating/improve-security/#remove-execution-of-strings 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.
  - buildbot 3y ago
    CSS3 is turing complete: https://accodeing.com/blog/2015/css3-proven-to-be-turing-complete https://accodeing.com/blog/2015/css3-proven-to-be-turing-com...
doctor_radium 3y ago
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?
- jupp0r 3y ago
  Filter lists are data, not code.
bilkow 3y ago
uBOL's FAQ entry: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#when-do-filter-lists-update 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/improve-security/#remove-execution-of-strings https://developer.chrome.com/docs/extensions/migrating/impro...
- bitvoid 3y ago
  That doesn't really state if that's a self-imposed limitation or limitation of Mv3.
  - bilkow 3y ago
    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 https://github.com/w3c/webextensions/issues/112
    - jsnell 3y ago
      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.
      - bilkow 3y ago
        > 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.

fgoesbrrr 3y ago

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

delroth 3y ago
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.
- zlg_codes 3y ago
  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.
tinus_hn 3y ago
Now there’s something Google Chrome would never do, phoning home.
- Dah00n 3y ago
  Not even Brave would do that. Wait..

dwaite 3y ago

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.

delroth 3y ago
> 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?
- charcircuit 3y ago
  https://developer.chrome.com/docs/extensions/migrating/improve-security/#configuration-drive https://developer.chrome.com/docs/extensions/migrating/impro... Chrome explicitly recommends downloading remote configuration.
mlyle 3y ago
https://developer.chrome.com/docs/extensions/migrating/improve-security/#remove-execution-of-strings 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.
- buildbot 3y ago
  CSS3 is turing complete: https://accodeing.com/blog/2015/css3-proven-to-be-turing-complete https://accodeing.com/blog/2015/css3-proven-to-be-turing-com...

doctor_radium 3y ago

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?

jupp0r 3y ago
Filter lists are data, not code.

bilkow 3y ago

uBOL's FAQ entry: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#when-do-filter-lists-update 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/improve-security/#remove-execution-of-strings https://developer.chrome.com/docs/extensions/migrating/impro...

bitvoid 3y ago
That doesn't really state if that's a self-imposed limitation or limitation of Mv3.
- bilkow 3y ago
  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 https://github.com/w3c/webextensions/issues/112
  - jsnell 3y ago
    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.
    - bilkow 3y ago
      > 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.