6 ms·

I like that Ars tries to defend ad blocking, but please, prepare better, maybe talk to actual developers and avoid false accusations. It’s completely okay to c

I like that Ars tries to defend ad blocking, but please, prepare better, maybe talk to actual developers and avoid false accusations. It’s completely okay to criticize Google for doing really controversial (to say the least) stuff like getting rid of blocking webRequest, but criticizing them for prohibiting inclusion of remote JS in the extension is simply bad work. They could do a minimal fact check, remote JS was never allowed in Mozilla Addons store. A bit more research and they’ll learn that cosmetic filters updates do not require an extension update. A little bit more research and one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year.

Wowfunhappy 3y ago
This is the first time I've really looked into Manifest V3, and I'm confused as to how the "no remote JS" restriction is enforced. What prevents a developer from using non-remote JS (code built into the extension) to tell the current web page to fetch remote JS from a server, and execute that? Obviously, web pages must be able to fetch remote JS, or the whole internet would break. Google could delist such an extension from the Chrome Web Store. But Chrome (unlike Firefox, grr!) allows extension sideloading, so if I was UBlock Origin I would just say screw the Web Store, download from our website. And then, once UBlock Origin can inject an unlimited amount of turing-complete Javascript onto the page, the sky is basically the limit... right?
- ameshkov 3y ago
  If the server is yours it will probably be rejected. Definitely will be rejected by Mozilla. Userscripts is a notable exception of this rule as in this case the user instructs the extension what JS to execute.
  - Wowfunhappy 3y ago
    Yes, but Chrome allows users to sideload extensions.
    - ameshkov 3y ago
      Firefox kinda also does. In both cases side loading is rather painful experience, thanks to all the malware that is exploiting the extensions feature.
      - Wowfunhappy 3y ago
        Firefox extensions don't need to be listed in the web store, but they must be signed by Mozilla, no exceptions. I have used both browsers, and I find sideloading in Chrome to be completely painless. I use many sideloaded extensions in Chrome (mostly because I wanted to make small edits to existing extensions). I guess I'm trying to figure out whether all this fuss is really a limitation of Manifest v3, or merely Chrome Web Store policy. If the latter, I don't see a problem as long as sideloading is possible, and I really hope UBlock Origin will just go that route. Sideloading is the real freedom which everyone should rally around and protect. (I am extremely unhappy with Mozilla's approach to this, if you can't tell.)
        ameshkov 3y ago
        The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform. This remote JS stuff is a CWS policy.
        Wowfunhappy 3y ago
        So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction. (I appreciate you answering my questions!)
        ameshkov 3y ago
        JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.
- deleted 3y ago
  [deleted]
- squeaky-clean 3y ago
  I used to run a homebrew'd extension to change my new tab page. Chrome makes it so annoying to use a sideloaded extension. Every time you start the browser, and every couple of hours when you open a new tab it will have a big popup warning you that an unsigned extension is running, and give you a big button to remove the extension that fires when you hit space or enter, and a tiny little subtext button to continue using the extension. After the 3rd time accidentally uninstalling the extension because I was typing in a search too quickly and not paying attention, I gave up on using it.
  - aardshark 3y ago
    You must be able to turn this off, because I've been running many homebrewed extensions for years and never encountered these popups.
  - Wowfunhappy 3y ago
    Huh, I've never seen this. Are you loading extensions via "load unpacked" (which is what I use) or some other method I'm unaware of?
Dylan16807 3y ago
The article is claiming that lists won't be able to self-update at all. That goes far beyond a ban on remote JS. > cosmetic filters updates do not require an extension update Cosmetic meaning what exactly? > remote JS was never allowed in Mozilla Addons store I don't see any issues with ublock in firefox, so what's going on there? > A little bit more research and one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year. That sounds like something that can and will randomly stop approving ad blocker updates more than once.
- ameshkov 3y ago
  The article’s claim is factually incorrect, self-update will also still be possible to implement even without the fast track. It will be more complicated than it is now as we’ll need to do that via differential updates, but nevertheless.
- ameshkov 3y ago
  > Cosmetic meaning what exactly? Filter lists are composed of two types of rules: “cosmetic” and “network”. Network rules define what needs to be done with web requests (block or redirect). In MV3 these rules should now be implemented via new declarative API. Cosmetic rules is a very wide subset of ad blocking rules that define how a web page needs to be changed. These are implemented the old way. > I don't see any issues with ublock in firefox, so what's going on there? uBlock Origin does not use remote JS so yeah, what’s going on with the article is a good question.
gorhill 3y ago
> one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year. My understanding is that no-review-fast-track is only for extensions which changes in DNR rulesets are only about block/allow/allowAllRequests rules. I don't see how comprehensive content blockers can push meaningful updates with only changes to block/allow/allowAllRequests rules and nothing else.
- ameshkov 3y ago
  It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. One more approach (a bit “hacky”) is to distribute cosmetic rules inside static rulesets (hide them in a separate “metadata” field). I personally like the fast track idea as we can use the CWS infra to distribute updates quickly, but this is not the only way. Differential updates are also possible and if they’re implemented, you can keep a normal release cycle (6 weeks for instance).
  - gorhill 3y ago
    > It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc. If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review. If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place? There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API. This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.
    - 3y ago
zlg_codes 3y ago
Why are people so eager to look away from the clear agenda that's playing out? It's not the time to be sticking one's head in the sand. Google is dead to me once they push Manifest v3.
- ameshkov 3y ago
  My point is that reporting must be accurate and factually correct.
  - zlg_codes 3y ago
    Google's showing their hand. You're here nitpicking. If something CAN be done, it usually WILL be done, especially if the actor is a business and the reward is power, influence, or profit. Will you be one of the ones 'giving Google a chance' once they play their hand next year?
- kccqzy 3y ago
  Because that agenda is hypothesis based on outsiders' observation of what Google is doing. It needs to be based on facts. Without facts, such an "agenda" is really just speculation and fear-mongering, not much better than the likes of Breitbart News. Speculation like this is easy. I can also just speculate that the Ars has an agenda to slander Google. Expand that to a couple hundred words and you have an article. Now get people to read it and become angry. That's basically the sorry state of online journalism. I have unsubscribed from Ars.
  - zlg_codes 3y ago
    Can you name a single thing Google's done that's earned them trust?
    - kccqzy 3y ago
      I'm more of a technologist than a product guy so I care more about the technologies coming out of Google. When I see major open source efforts like tensorflow or k8s I see goodwill and trust. Outside the realm of software, when I see principles or ideas or algorithms like CoDel, BBR congestion control, and SPDY (later becoming HTTP/2) and even later QUIC, MASQUE, I see the same (please excuse me for listing networking technologies because that's where my recent interests are). Here's a very simple thought experiment: if all the above technologies came from a different company say Cloudflare would you consider these earning them trust? The answer is an unequivocal yes. The only reason why you might be unable to name a single thing Google did to earn them trust is perhaps because of rampant brainwashing by the anti-Google rhetoric.

Wowfunhappy 3y ago

This is the first time I've really looked into Manifest V3, and I'm confused as to how the "no remote JS" restriction is enforced. What prevents a developer from using non-remote JS (code built into the extension) to tell the current web page to fetch remote JS from a server, and execute that? Obviously, web pages must be able to fetch remote JS, or the whole internet would break. Google could delist such an extension from the Chrome Web Store. But Chrome (unlike Firefox, grr!) allows extension sideloading, so if I was UBlock Origin I would just say screw the Web Store, download from our website. And then, once UBlock Origin can inject an unlimited amount of turing-complete Javascript onto the page, the sky is basically the limit... right?

ameshkov 3y ago
If the server is yours it will probably be rejected. Definitely will be rejected by Mozilla. Userscripts is a notable exception of this rule as in this case the user instructs the extension what JS to execute.
- Wowfunhappy 3y ago
  Yes, but Chrome allows users to sideload extensions.
  - ameshkov 3y ago
    Firefox kinda also does. In both cases side loading is rather painful experience, thanks to all the malware that is exploiting the extensions feature.
    - Wowfunhappy 3y ago
      Firefox extensions don't need to be listed in the web store, but they must be signed by Mozilla, no exceptions. I have used both browsers, and I find sideloading in Chrome to be completely painless. I use many sideloaded extensions in Chrome (mostly because I wanted to make small edits to existing extensions). I guess I'm trying to figure out whether all this fuss is really a limitation of Manifest v3, or merely Chrome Web Store policy. If the latter, I don't see a problem as long as sideloading is possible, and I really hope UBlock Origin will just go that route. Sideloading is the real freedom which everyone should rally around and protect. (I am extremely unhappy with Mozilla's approach to this, if you can't tell.)
      - ameshkov 3y ago
        The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform. This remote JS stuff is a CWS policy.
        Wowfunhappy 3y ago
        So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction. (I appreciate you answering my questions!)
        ameshkov 3y ago
        JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.
deleted 3y ago
[deleted]
squeaky-clean 3y ago
I used to run a homebrew'd extension to change my new tab page. Chrome makes it so annoying to use a sideloaded extension. Every time you start the browser, and every couple of hours when you open a new tab it will have a big popup warning you that an unsigned extension is running, and give you a big button to remove the extension that fires when you hit space or enter, and a tiny little subtext button to continue using the extension. After the 3rd time accidentally uninstalling the extension because I was typing in a search too quickly and not paying attention, I gave up on using it.
- aardshark 3y ago
  You must be able to turn this off, because I've been running many homebrewed extensions for years and never encountered these popups.
- Wowfunhappy 3y ago
  Huh, I've never seen this. Are you loading extensions via "load unpacked" (which is what I use) or some other method I'm unaware of?

Dylan16807 3y ago

The article is claiming that lists won't be able to self-update at all. That goes far beyond a ban on remote JS. > cosmetic filters updates do not require an extension update Cosmetic meaning what exactly? > remote JS was never allowed in Mozilla Addons store I don't see any issues with ublock in firefox, so what's going on there? > A little bit more research and one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year. That sounds like something that can and will randomly stop approving ad blocker updates more than once.

ameshkov 3y ago
The article’s claim is factually incorrect, self-update will also still be possible to implement even without the fast track. It will be more complicated than it is now as we’ll need to do that via differential updates, but nevertheless.
ameshkov 3y ago
> Cosmetic meaning what exactly? Filter lists are composed of two types of rules: “cosmetic” and “network”. Network rules define what needs to be done with web requests (block or redirect). In MV3 these rules should now be implemented via new declarative API. Cosmetic rules is a very wide subset of ad blocking rules that define how a web page needs to be changed. These are implemented the old way. > I don't see any issues with ublock in firefox, so what's going on there? uBlock Origin does not use remote JS so yeah, what’s going on with the article is a good question.

gorhill 3y ago

> one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year. My understanding is that no-review-fast-track is only for extensions which changes in DNR rulesets are only about block/allow/allowAllRequests rules. I don't see how comprehensive content blockers can push meaningful updates with only changes to block/allow/allowAllRequests rules and nothing else.

ameshkov 3y ago
It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. One more approach (a bit “hacky”) is to distribute cosmetic rules inside static rulesets (hide them in a separate “metadata” field). I personally like the fast track idea as we can use the CWS infra to distribute updates quickly, but this is not the only way. Differential updates are also possible and if they’re implemented, you can keep a normal release cycle (6 weeks for instance).
- gorhill 3y ago
  > It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc. If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review. If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place? There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API. This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.
  - 3y ago

zlg_codes 3y ago

Why are people so eager to look away from the clear agenda that's playing out? It's not the time to be sticking one's head in the sand. Google is dead to me once they push Manifest v3.

ameshkov 3y ago
My point is that reporting must be accurate and factually correct.
- zlg_codes 3y ago
  Google's showing their hand. You're here nitpicking. If something CAN be done, it usually WILL be done, especially if the actor is a business and the reward is power, influence, or profit. Will you be one of the ones 'giving Google a chance' once they play their hand next year?
kccqzy 3y ago
Because that agenda is hypothesis based on outsiders' observation of what Google is doing. It needs to be based on facts. Without facts, such an "agenda" is really just speculation and fear-mongering, not much better than the likes of Breitbart News. Speculation like this is easy. I can also just speculate that the Ars has an agenda to slander Google. Expand that to a couple hundred words and you have an article. Now get people to read it and become angry. That's basically the sorry state of online journalism. I have unsubscribed from Ars.
- zlg_codes 3y ago
  Can you name a single thing Google's done that's earned them trust?
  - kccqzy 3y ago
    I'm more of a technologist than a product guy so I care more about the technologies coming out of Google. When I see major open source efforts like tensorflow or k8s I see goodwill and trust. Outside the realm of software, when I see principles or ideas or algorithms like CoDel, BBR congestion control, and SPDY (later becoming HTTP/2) and even later QUIC, MASQUE, I see the same (please excuse me for listing networking technologies because that's where my recent interests are). Here's a very simple thought experiment: if all the above technologies came from a different company say Cloudflare would you consider these earning them trust? The answer is an unequivocal yes. The only reason why you might be unable to name a single thing Google did to earn them trust is perhaps because of rampant brainwashing by the anti-Google rhetoric.