8 ms·

Just so I understand correctly: This version removes all of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, ra

Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, rather than taking full advantage of all of the actual MV3 APIs? For example, this commit removes the "scriplet injection" and cosmetic filtering features, which AFAIK work perfectly fine on MV3? if broad "read/modify data" permission is to be used, than there is not much point for an MV3 version over MV2, just use the MV2 version if you want to benefit all the features which can't be implemented without broad "read/modify data" permission. Huh? But ... the "read/modify data" permission isn't getting removed by MV3? I don't understand how this follows. This is like saying "Google implemented all of the same things we could do in MV2 in MV3, so we went ahead and removed all of the features anyway". I don't see any way to interpret this as anything except cutting off your own nose to spite the face of Google. It certainly doesn't seem to be a good faith attempt to reproduce the features of uBlock within the new technical framework of MV3.

michaelmrose 4y ago
Google is an ad company. The logical strategy is embrace extend extinguish ad blocking. If your extension is getting attacked and stripped of functionality minimal investment in keeping it working likely to continue to work the longest is logical
- nightpool 4y ago
  Many people have responded to this argument across many different threads, but just to reiterate: this is just the exact opposite of true. Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.
  - michaelmrose 4y ago
    MV3 has zero privacy benefits as it doesn't stop the same extensions from snooping but it does force substantial limitations like not having a separate list separated from the extension itself and an artificial limitation on the size of its blocklist. It is not expected that mv3 immediately destroys all ad blocking but if you look at the fact that google already makes such impossible on mobile you can surmise that it is a likely step towards eliminating all adblocking in the future. Especially since they have so obviously lied to everyone about the motivation for the change. The end game is adblocking that blocks "unacceptable" ads in the name of protecting you from content that is offensive, adult, malware, or experience destroyingly bad while allowing in offensive google ads. In the name of not getting sued select partners will be allowed to prove they apply the same standards and will be allowed to access your eyeballs. Feel free to revisit this in 3-5 years when I'm obviously right.
- thiht 4y ago
  > The logical strategy is embrace extend extinguish ad blocking The logical strategy is to extinguish. They never embraced or extended it.
  - michaelmrose 4y ago
    Implementing what amounts to ad blocking in your browser which all extensions must necessarily be mere lists of what to block rather than complex programs that examine and modify data IS the embrace. Extending it would involve either implementing acceptable ads functionality that was optional. Extinguish is making it mandatory in order to be listed on the chrome web store and allowing the browser to transmit some certification that it doesn't have an extension installed that would modify data in transit to ensure "security" making it hard to use the modern web with a browser that didn't transmit such. Locally installing extensions is only for development so that any such modification will effectively break such a seal and make it impossible for you to view $SOME_RANDOM_GOOGLE_ADS_USING_SITE which will complain your browser is insecure and refuse to work kind of like sites presently block adblockers but with browser support making it much harder to avoid.
stonogo 4y ago
You are conflating a "present/absent" question of this permission with Google's stated intent. The key modifier here is broad "read/modify data" permission. If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions. Furthmore the webRequest API has been nerfed to the point that it cannot block requests any more, only track them. The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.
- nightpool 4y ago
  > If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions. Do you have a source for this? Have other ad blocking extensions been removed from the store? I find it very hard to believe that Google would block uBlock over something so clearly and obviously required for its functioning when they've said over and over again that making sure ad blocking extensions continue to work is a high priority for them. > The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs. Well, the stats from the commit in question clearly disagree with you—of 22,245 rules, only 145 use unsupported regexes. How is DNR "not flexible" enough here?
  - stonogo 4y ago
    I can't provide a source for Google axing a too-invasive extension, because they've never been straightforward about it. My favorite excuse was that the extension's description was "too detailed." As for the other, here you go: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-1236416215 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...
  - gorhill 4y ago
    > How is DNR "not flexible" enough here? DNR does not allow uBO's _Block media elements larger than [x] KB_[1]. DNR does not allow to know which network request was blocked by what rule. To do so requires the `declarativeNetRequestFeedback` permission, which is available only on locally unpacked extensions, for debugging purpose. This prevents porting to MV3 uBO's overview panel[2], including the "advanced user" version to set firewall-like rules[3], and uBO's logger[4]. Furthermore, the filter-matching algorithm of DNR does not match the filter-matching algorithm of uBO regarding redirection. In uBO, redirect filters do not compete with block filters, they are looked-up after a network request has been blocked. With DNR, redirect rules competes with block rules, such that uBO's `redirect-rule=` filters can't be ported. * * * [1] https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-large-media-elements https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-... [2] https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-user-interface#the-overview-panel https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-us... [3] https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu... [4] https://github.com/gorhill/uBlock/wiki/The-logger https://github.com/gorhill/uBlock/wiki/The-logger
deleted 4y ago
[deleted]
sgc 4y ago
Maybe I am missing something here. But google is a well-known pull-the-rug-from-under-you type company, with a long proven track record of doing just that. Don't use undocumented, not officially supported anything from them. ever. Don't use apis that go against their stated goals. They WILL remove them. Unless MV3 has officially committed to a changed changed scope to allow this, it is irrelevant if it incidentally works.
- nightpool 4y ago
  I'm talking about features that the Chrome team has explicitly said time and time again will continue to work, like content scripts and user styles (cosmetic filters), and which MV3 never threatened in the first place. It would be ludicrous to consider these "undocumented". It's hard for me to see any other reason for gorhill to remove these features from the MV3 version of the extension except out of some perverse inclination to twist around the meaning of the Chrome team's words to support the conclusion that he obviously wants to find (that Chrome is trying to kill ad-blockers)—when in fact the *stated goals* of the extension team have always been the exact opposite (to provide APIs and extension points that allow ad blockers to continue to work)
- deleted 4y ago
  [deleted]
ohgodplsno 4y ago
> this commit removes the "scriplet injection" Considering this is stated in ManifestV3's announcement and that no APIs have been made for it: > Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code. This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. Server communication (potentially changing extension behavior) will still be allowed. This will help us better review the extensions uploaded, and keep our users safe. We will leverage a minimum required CSP to help enforce this (though it will not be 100% unpreventable, and we will require policy and manual review enforcement as well). Scriptlet injection is as good as dead. > and cosmetic filtering features, Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded. > the "read/modify data" permission isn't getting removed by MV3? No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted. So, no, Google, as usual when they implement a new API, does half assed shit, breaks compatibility, forces everyone to follow on their bad decisions before deprecating it later. Going all in on MV3 is just bringing yourself to the slaughter, and MV3 should be laughed off by any serious extension developer.
- caladin 4y ago
  One interesting consequence of this is that Google's own javascript api client will no longer work with MV3 and there are apparently no plans to ever make it work. See https://github.com/google/google-api-javascript-client/issues/713 https://github.com/google/google-api-javascript-client/issue... Chromium bug marked WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=1164452 https://bugs.chromium.org/p/chromium/issues/detail?id=116445... Updated readme: https://github.com/google/google-api-javascript-client/blob/master/docs/start.md#supported-environments https://github.com/google/google-api-javascript-client/blob/... So effectively this means extensions on MV3 can't easily access Google apis, which is quite unfortunate since Chrome extensions in particular made Google authentication super straightforward (piggybacking off of chrome's built-in google authentication). If someone knows a better way I'd love to hear it. I believe the reason that the current incarnation of the javascript library won't work is because it modifies the dom to add script tags to fetch and run the api library (or components of it), which is specifically what MV3 will disallow AFAIK.
gorhill 4y ago
> the "read/modify data" permission isn't getting removed by MV3? The stated reason for the removal of the blocking webRequest API was to avoid broad permissions to read/modify data on all websites in the name of privacy/security. What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms beyond what the declarativeNetRequest API allows? The point is to show that if you respect the stated reasons for the declarativeNetRequest API deprecating the blocking webRequest API, that is what you get.
- SquareWheel 4y ago
  You seem to be confirming nightpool's comment. That this is an intentionally-limited release. I think that's fine. It's good to have an adblocker that uses minimal permissions. But it seems like people will use this to argue that MV3 is less capable than it really is. Maybe UBO Plus (MV3) will come later that enables those feature.
  - gorhill 4y ago
    It can never be "plus" compared to what uBO is currently with MV2, there are features and capabilities that can't be ported to MV3.
    - SquareWheel 4y ago
      I understand that, but it seems like the most frequently-used features (eg. cosmetic filtering) are possible in MV3. So a version with those features included would still offer value. Correct me if I'm wrong, but it seems most of the missing capabilities are power user features - even by HN standards. It's of course your discretion if that's something you wish to work on. I think a Minus and Plus version (or "Regular" if you prefer) offer a nice option for users to choose between. But I understand if the development overhead of managing two versions cannot be justified.
- nightpool 4y ago
  > What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms The point would be to have those features, obviously? Cosmetic filtering is extremely important, there was never any possibility that MV3 was going to remove it, and you just removed it yourself for absolutely no reason. I'm sorry, but if you're just removing features from your extension to make a "point" about "respecting stated reasons" then I don't think people should take what you say about it seriously. This might be an art project or a political protest, but people shouldn't confuse it for an actual attempt at extension development. You're taking a single reason that they gave, two years ago, and pretending like it should dictate every single thing you should do with your extension, out of some weird form of stubbornness and bloody-mindedness.
somehnacct3757 4y ago
I do think there's a bit of sour grapes. You can only use the MV2 version until January. After that the main point to using the MV3 extension will be that it exists. I sort of like the idea of UBO Minus, regardless of whether they do a full MV3 version of UBO later. It's more private than UBO could ever be. If it's enough, it's actually quite a nice extension. Methinks a competitor ad blocker leaning into MV3 and claiming the 'first MV3 ad blocker' title last week was a glass of cold water for UBO devs. MV3 is happening, and usershare is at risk. But, in addition to all that, I also think the main objective of MV3 is to hamstring ad blockers. Very very elegantly hamstring ad blockers.
- bsilvereagle 4y ago
  > usershare is at risk My impression from way back in the uMatrix days was that marketshare is not a concern for gorhill and that the u* family are a labor of love to improve the internet for everyone.
  - pabs3 4y ago
    Some folks still use uMatrix and wish uBlock had an advanced advanced mode to replace it :)
    - pmontra 4y ago
      I do keep using uMatrix. Its matrix UI is a nearly perfect. I also use uBlock Origin and I can't understand how to achieve the same results with the mini-matrix in its UI. ++ -- ??? It lacks the columns that explain what you're blocking or allowing. I read the documentation more than once and I still don't understand how to use it. Maybe I lack the incentive because uMatrix still works and it's so much better at that.
      - Arnavion 4y ago
        https://news.ycombinator.com/item?id=26284124 https://news.ycombinator.com/item?id=26284124

Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, ra

michaelmrose 4y ago

Google is an ad company. The logical strategy is embrace extend extinguish ad blocking. If your extension is getting attacked and stripped of functionality minimal investment in keeping it working likely to continue to work the longest is logical

nightpool 4y ago
Many people have responded to this argument across many different threads, but just to reiterate: this is just the exact opposite of true. Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.
- michaelmrose 4y ago
  MV3 has zero privacy benefits as it doesn't stop the same extensions from snooping but it does force substantial limitations like not having a separate list separated from the extension itself and an artificial limitation on the size of its blocklist. It is not expected that mv3 immediately destroys all ad blocking but if you look at the fact that google already makes such impossible on mobile you can surmise that it is a likely step towards eliminating all adblocking in the future. Especially since they have so obviously lied to everyone about the motivation for the change. The end game is adblocking that blocks "unacceptable" ads in the name of protecting you from content that is offensive, adult, malware, or experience destroyingly bad while allowing in offensive google ads. In the name of not getting sued select partners will be allowed to prove they apply the same standards and will be allowed to access your eyeballs. Feel free to revisit this in 3-5 years when I'm obviously right.
thiht 4y ago
> The logical strategy is embrace extend extinguish ad blocking The logical strategy is to extinguish. They never embraced or extended it.
- michaelmrose 4y ago
  Implementing what amounts to ad blocking in your browser which all extensions must necessarily be mere lists of what to block rather than complex programs that examine and modify data IS the embrace. Extending it would involve either implementing acceptable ads functionality that was optional. Extinguish is making it mandatory in order to be listed on the chrome web store and allowing the browser to transmit some certification that it doesn't have an extension installed that would modify data in transit to ensure "security" making it hard to use the modern web with a browser that didn't transmit such. Locally installing extensions is only for development so that any such modification will effectively break such a seal and make it impossible for you to view $SOME_RANDOM_GOOGLE_ADS_USING_SITE which will complain your browser is insecure and refuse to work kind of like sites presently block adblockers but with browser support making it much harder to avoid.

stonogo 4y ago

You are conflating a "present/absent" question of this permission with Google's stated intent. The key modifier here is broad "read/modify data" permission. If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions. Furthmore the webRequest API has been nerfed to the point that it cannot block requests any more, only track them. The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.

nightpool 4y ago
> If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions. Do you have a source for this? Have other ad blocking extensions been removed from the store? I find it very hard to believe that Google would block uBlock over something so clearly and obviously required for its functioning when they've said over and over again that making sure ad blocking extensions continue to work is a high priority for them. > The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs. Well, the stats from the commit in question clearly disagree with you—of 22,245 rules, only 145 use unsupported regexes. How is DNR "not flexible" enough here?
- stonogo 4y ago
  I can't provide a source for Google axing a too-invasive extension, because they've never been straightforward about it. My favorite excuse was that the extension's description was "too detailed." As for the other, here you go: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-1236416215 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...
- gorhill 4y ago
  > How is DNR "not flexible" enough here? DNR does not allow uBO's _Block media elements larger than [x] KB_[1]. DNR does not allow to know which network request was blocked by what rule. To do so requires the `declarativeNetRequestFeedback` permission, which is available only on locally unpacked extensions, for debugging purpose. This prevents porting to MV3 uBO's overview panel[2], including the "advanced user" version to set firewall-like rules[3], and uBO's logger[4]. Furthermore, the filter-matching algorithm of DNR does not match the filter-matching algorithm of uBO regarding redirection. In uBO, redirect filters do not compete with block filters, they are looked-up after a network request has been blocked. With DNR, redirect rules competes with block rules, such that uBO's `redirect-rule=` filters can't be ported. * * * [1] https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-large-media-elements https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-... [2] https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-user-interface#the-overview-panel https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-us... [3] https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu... [4] https://github.com/gorhill/uBlock/wiki/The-logger https://github.com/gorhill/uBlock/wiki/The-logger

deleted 4y ago

[deleted]

sgc 4y ago

Maybe I am missing something here. But google is a well-known pull-the-rug-from-under-you type company, with a long proven track record of doing just that. Don't use undocumented, not officially supported anything from them. ever. Don't use apis that go against their stated goals. They WILL remove them. Unless MV3 has officially committed to a changed changed scope to allow this, it is irrelevant if it incidentally works.

nightpool 4y ago
I'm talking about features that the Chrome team has explicitly said time and time again will continue to work, like content scripts and user styles (cosmetic filters), and which MV3 never threatened in the first place. It would be ludicrous to consider these "undocumented". It's hard for me to see any other reason for gorhill to remove these features from the MV3 version of the extension except out of some perverse inclination to twist around the meaning of the Chrome team's words to support the conclusion that he obviously wants to find (that Chrome is trying to kill ad-blockers)—when in fact the *stated goals* of the extension team have always been the exact opposite (to provide APIs and extension points that allow ad blockers to continue to work)
deleted 4y ago
[deleted]

ohgodplsno 4y ago

> this commit removes the "scriplet injection" Considering this is stated in ManifestV3's announcement and that no APIs have been made for it: > Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code. This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. Server communication (potentially changing extension behavior) will still be allowed. This will help us better review the extensions uploaded, and keep our users safe. We will leverage a minimum required CSP to help enforce this (though it will not be 100% unpreventable, and we will require policy and manual review enforcement as well). Scriptlet injection is as good as dead. > and cosmetic filtering features, Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded. > the "read/modify data" permission isn't getting removed by MV3? No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted. So, no, Google, as usual when they implement a new API, does half assed shit, breaks compatibility, forces everyone to follow on their bad decisions before deprecating it later. Going all in on MV3 is just bringing yourself to the slaughter, and MV3 should be laughed off by any serious extension developer.

caladin 4y ago
One interesting consequence of this is that Google's own javascript api client will no longer work with MV3 and there are apparently no plans to ever make it work. See https://github.com/google/google-api-javascript-client/issues/713 https://github.com/google/google-api-javascript-client/issue... Chromium bug marked WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=1164452 https://bugs.chromium.org/p/chromium/issues/detail?id=116445... Updated readme: https://github.com/google/google-api-javascript-client/blob/master/docs/start.md#supported-environments https://github.com/google/google-api-javascript-client/blob/... So effectively this means extensions on MV3 can't easily access Google apis, which is quite unfortunate since Chrome extensions in particular made Google authentication super straightforward (piggybacking off of chrome's built-in google authentication). If someone knows a better way I'd love to hear it. I believe the reason that the current incarnation of the javascript library won't work is because it modifies the dom to add script tags to fetch and run the api library (or components of it), which is specifically what MV3 will disallow AFAIK.

gorhill 4y ago

> the "read/modify data" permission isn't getting removed by MV3? The stated reason for the removal of the blocking webRequest API was to avoid broad permissions to read/modify data on all websites in the name of privacy/security. What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms beyond what the declarativeNetRequest API allows? The point is to show that if you respect the stated reasons for the declarativeNetRequest API deprecating the blocking webRequest API, that is what you get.

SquareWheel 4y ago
You seem to be confirming nightpool's comment. That this is an intentionally-limited release. I think that's fine. It's good to have an adblocker that uses minimal permissions. But it seems like people will use this to argue that MV3 is less capable than it really is. Maybe UBO Plus (MV3) will come later that enables those feature.
- gorhill 4y ago
  It can never be "plus" compared to what uBO is currently with MV2, there are features and capabilities that can't be ported to MV3.
  - SquareWheel 4y ago
    I understand that, but it seems like the most frequently-used features (eg. cosmetic filtering) are possible in MV3. So a version with those features included would still offer value. Correct me if I'm wrong, but it seems most of the missing capabilities are power user features - even by HN standards. It's of course your discretion if that's something you wish to work on. I think a Minus and Plus version (or "Regular" if you prefer) offer a nice option for users to choose between. But I understand if the development overhead of managing two versions cannot be justified.
nightpool 4y ago
> What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms The point would be to have those features, obviously? Cosmetic filtering is extremely important, there was never any possibility that MV3 was going to remove it, and you just removed it yourself for absolutely no reason. I'm sorry, but if you're just removing features from your extension to make a "point" about "respecting stated reasons" then I don't think people should take what you say about it seriously. This might be an art project or a political protest, but people shouldn't confuse it for an actual attempt at extension development. You're taking a single reason that they gave, two years ago, and pretending like it should dictate every single thing you should do with your extension, out of some weird form of stubbornness and bloody-mindedness.

somehnacct3757 4y ago

I do think there's a bit of sour grapes. You can only use the MV2 version until January. After that the main point to using the MV3 extension will be that it exists. I sort of like the idea of UBO Minus, regardless of whether they do a full MV3 version of UBO later. It's more private than UBO could ever be. If it's enough, it's actually quite a nice extension. Methinks a competitor ad blocker leaning into MV3 and claiming the 'first MV3 ad blocker' title last week was a glass of cold water for UBO devs. MV3 is happening, and usershare is at risk. But, in addition to all that, I also think the main objective of MV3 is to hamstring ad blockers. Very very elegantly hamstring ad blockers.

bsilvereagle 4y ago
> usershare is at risk My impression from way back in the uMatrix days was that marketshare is not a concern for gorhill and that the u* family are a labor of love to improve the internet for everyone.
- pabs3 4y ago
  Some folks still use uMatrix and wish uBlock had an advanced advanced mode to replace it :)
  - pmontra 4y ago
    I do keep using uMatrix. Its matrix UI is a nearly perfect. I also use uBlock Origin and I can't understand how to achieve the same results with the mini-matrix in its UI. ++ -- ??? It lacks the columns that explain what you're blocking or allowing. I read the documentation more than once and I still don't understand how to use it. Maybe I lack the incentive because uMatrix still works and it's so much better at that.
    - Arnavion 4y ago
      https://news.ycombinator.com/item?id=26284124 https://news.ycombinator.com/item?id=26284124