3 ms·

> What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms Th

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

gorhill 4y ago
> removed it yourself for absolutely no reason I clearly stated the reason: to avoid having to require broad "read/modify data on all websites" permission. I purposefully decided to create a permission-less version of uBO for people who would rather not grant broad "read/modify data on all websites". > You're taking a single reason that they gave, two years ago The current documentation regarding the purpose of declarativeNetRequest API deprecating the blocking webRequest API[1]: > Using this declarative approach dramatically reduces the need for persistent host permissions. My goal is to create a permission-less version of uBO and this is what I did. I am sure this could appeal to some people out there, as many over time have echoed that broad permissions to "read/modify data on all websites" is scary -- it's a recurring comment for those who support Chromium's deprecation of the blocking webRequest API in favor of the declarativeNetRequest API. So this is a content blocker for those people. For those who can't live without cosmetic filtering and all the other goodies, there are other options out there. I don't understand what you perceive this negatively. * * * [1] https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#network-request-modification https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o...
- deleted 4y ago
  [deleted]
- concinds 4y ago
  I initially punished a comment disagreeing with you, but after thinking about it more, I agree. Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites"; just like Apple did, Chrome's whole idea with Manifest v3 was to make that go away. Frankly, with the genuinely malicious extensions people keep installing, probably for the best. Furthermore having uBlock Origin "continue to behave as normal" will confuse users and make them think uBO is still blocking everything users expect it to (i.e. tracking), which can surely endanger some users.
  - nightpool 4y ago
    Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites" Where have they "clearly signaled this"? Gorhil even disproves this in his own comment: he links to an ad blocker in the Chrome webstore that uses MV3 and has been approved, even though it uses the "Read/write data on all websites" permission.
    - concinds 4y ago
      I got it from this comment: (https://news.ycombinator.com/item?id=32755925); https://news.ycombinator.com/item?id=32755925); and Chromium's official blog that hints at that: https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html https://blog.chromium.org/2020/12/manifest-v3-now-available-... > To give users greater visibility and control over how extensions use and share their data, we’re moving to an extensions model that makes more permissions optional and allows users to withhold sensitive permissions at install time. Long-term, extension developers should expect users to opt in or out of permissions at any time. > For extensions that currently require passive access to web activity, we’re introducing and continuing to iterate on new functionality that allows developers to deliver these use cases while preserving user privacy. For example, our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data. > The declarativeNetRequest API is an example of how Chrome is working to enable extensions, including ad blockers, to continue delivering their core functionality without requiring the extension to have access to potentially sensitive user data. This will allow many of the powerful extensions in our ecosystem to continue to provide a seamless user experience while still respecting user privacy. Basically, Chrome is hoping to use the same psychological effect as Apple's "Ad Tracking Transparency" (the opt-in screen for cross-app tracking) to make people opt-in for "read/write data on all sites" permission, to try to transition the amount of adblockers with that permission from 100% (currently) to ~20% (the amount of people who opt-in to tracking on iOS) by scaring users about extension permissions.

gorhill 4y ago

> removed it yourself for absolutely no reason I clearly stated the reason: to avoid having to require broad "read/modify data on all websites" permission. I purposefully decided to create a permission-less version of uBO for people who would rather not grant broad "read/modify data on all websites". > You're taking a single reason that they gave, two years ago The current documentation regarding the purpose of declarativeNetRequest API deprecating the blocking webRequest API[1]: > Using this declarative approach dramatically reduces the need for persistent host permissions. My goal is to create a permission-less version of uBO and this is what I did. I am sure this could appeal to some people out there, as many over time have echoed that broad permissions to "read/modify data on all websites" is scary -- it's a recurring comment for those who support Chromium's deprecation of the blocking webRequest API in favor of the declarativeNetRequest API. So this is a content blocker for those people. For those who can't live without cosmetic filtering and all the other goodies, there are other options out there. I don't understand what you perceive this negatively. * * * [1] https://developer.chrome.com/docs/extensions/mv3/intro/mv3-overview/#network-request-modification https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o...

deleted 4y ago
[deleted]
concinds 4y ago
I initially punished a comment disagreeing with you, but after thinking about it more, I agree. Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites"; just like Apple did, Chrome's whole idea with Manifest v3 was to make that go away. Frankly, with the genuinely malicious extensions people keep installing, probably for the best. Furthermore having uBlock Origin "continue to behave as normal" will confuse users and make them think uBO is still blocking everything users expect it to (i.e. tracking), which can surely endanger some users.
- nightpool 4y ago
  Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites" Where have they "clearly signaled this"? Gorhil even disproves this in his own comment: he links to an ad blocker in the Chrome webstore that uses MV3 and has been approved, even though it uses the "Read/write data on all websites" permission.
  - concinds 4y ago
    I got it from this comment: (https://news.ycombinator.com/item?id=32755925); https://news.ycombinator.com/item?id=32755925); and Chromium's official blog that hints at that: https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html https://blog.chromium.org/2020/12/manifest-v3-now-available-... > To give users greater visibility and control over how extensions use and share their data, we’re moving to an extensions model that makes more permissions optional and allows users to withhold sensitive permissions at install time. Long-term, extension developers should expect users to opt in or out of permissions at any time. > For extensions that currently require passive access to web activity, we’re introducing and continuing to iterate on new functionality that allows developers to deliver these use cases while preserving user privacy. For example, our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data. > The declarativeNetRequest API is an example of how Chrome is working to enable extensions, including ad blockers, to continue delivering their core functionality without requiring the extension to have access to potentially sensitive user data. This will allow many of the powerful extensions in our ecosystem to continue to provide a seamless user experience while still respecting user privacy. Basically, Chrome is hoping to use the same psychological effect as Apple's "Ad Tracking Transparency" (the opt-in screen for cross-app tracking) to make people opt-in for "read/write data on all sites" permission, to try to transition the amount of adblockers with that permission from 100% (currently) to ~20% (the amount of people who opt-in to tracking on iOS) by scaring users about extension permissions.