prehistoric-systems/uBlock
1
0
Fork 0
mirror of https://github.com/gorhill/uBlock.git synced 2026-03-11 09:04:36 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
uBlock/platform/mv3/firefox/manifest.json

55 lines
1.1 KiB
JSON
Raw Normal View History

Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
{
Add per-site on/off switch to mv3 experimental version
2022-09-07 14:15:36 +00:00
"action": {
[mv3] Put icon in nav bar by default Related issue: https://github.com/uBlockOrigin/uBlock-issues/issues/2781
2023-08-20 13:35:16 +00:00
"default_area": "navbar",
Add per-site on/off switch to mv3 experimental version
2022-09-07 14:15:36 +00:00
"default_icon": {
"16": "img/icon_16.png",
"32": "img/icon_32.png",
"64": "img/icon_64.png"
},
"default_popup": "popup.html"
},
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
"author": "Raymond Hill",
Add per-site on/off switch to mv3 experimental version
2022-09-07 14:15:36 +00:00
"background": {
Fix mv3 builds
2023-04-11 13:35:31 +00:00
"scripts": [ "/js/background.js" ],
"type": "module"
Create a MVP version of uBOLite for Firefox What does not work at the time of commit: Cosmetic filtering does not work: The content scripts responsible for cosmetic filtering fail when trying to inject the stylesheets through document.adoptedStyleSheets, with the following error message: XrayWrapper denied access to property Symbol.iterator (reason: object is not safely Xrayable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. ... css-declarative.js:106:8 A possible solution is to inject those content scripts in the MAIN world. However Firefox scripting API does not support MAIN world injection at the moment. Scriptlet-filtering does not work: Because scriptlet code needs to be injected in the MAIN world, and this is currently not supported by Firefox's scripting API, see https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 There is no count badge on the toolbar icon in Firefox, as it currently does not support the `DNR.setExtensionActionOptions` method. Other than the above issues, it does appear uBO is blocking properly with no error reported in the dev console. The adoptedStyleSheets issue though is worrisome, as the cosmetic filtering content scripts were designed with ISOLATED world injection in mind. Being forced to inject in MAIN world (when available) make things a bit more complicated as uBO has to ensure it's global variables do not leak into the page.
2023-04-07 14:19:43 +00:00
},
"browser_specific_settings": {
"gecko": {
"id": "uBOLite@raymondhill.net",
[mv3] Fix strict_min_version for Firefox
2023-07-13 20:04:25 +00:00
"strict_min_version": "114.0"
Add `browser_specific_settings.gecko_android` to Firefox manifests Reference: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings
2023-10-11 16:32:38 +00:00
},
"gecko_android": {
"strict_min_version": "114.0"
Create a MVP version of uBOLite for Firefox What does not work at the time of commit: Cosmetic filtering does not work: The content scripts responsible for cosmetic filtering fail when trying to inject the stylesheets through document.adoptedStyleSheets, with the following error message: XrayWrapper denied access to property Symbol.iterator (reason: object is not safely Xrayable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. ... css-declarative.js:106:8 A possible solution is to inject those content scripts in the MAIN world. However Firefox scripting API does not support MAIN world injection at the moment. Scriptlet-filtering does not work: Because scriptlet code needs to be injected in the MAIN world, and this is currently not supported by Firefox's scripting API, see https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 There is no count badge on the toolbar icon in Firefox, as it currently does not support the `DNR.setExtensionActionOptions` method. Other than the above issues, it does appear uBO is blocking properly with no error reported in the dev console. The adoptedStyleSheets issue though is worrisome, as the cosmetic filtering content scripts were designed with ISOLATED world injection in mind. Being forced to inject in MAIN world (when available) make things a bit more complicated as uBO has to ensure it's global variables do not leak into the page.
2023-04-07 14:19:43 +00:00
}
},
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
"declarative_net_request": {
"rule_resources": [
]
},
[mv3] Add ability to enable/disable filter lists
2022-09-13 21:44:24 +00:00
"default_locale": "en",
Use translated strings in manifest
2022-09-14 13:32:59 +00:00
"description": "__MSG_extShortDesc__",
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
"icons": {
"16": "img/icon_16.png",
"32": "img/icon_32.png",
"64": "img/icon_64.png",
"128": "img/icon_128.png"
},
"manifest_version": 3,
Use translated strings in manifest
2022-09-14 13:32:59 +00:00
"name": "__MSG_extName__",
Create a MVP version of uBOLite for Firefox What does not work at the time of commit: Cosmetic filtering does not work: The content scripts responsible for cosmetic filtering fail when trying to inject the stylesheets through document.adoptedStyleSheets, with the following error message: XrayWrapper denied access to property Symbol.iterator (reason: object is not safely Xrayable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. ... css-declarative.js:106:8 A possible solution is to inject those content scripts in the MAIN world. However Firefox scripting API does not support MAIN world injection at the moment. Scriptlet-filtering does not work: Because scriptlet code needs to be injected in the MAIN world, and this is currently not supported by Firefox's scripting API, see https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 There is no count badge on the toolbar icon in Firefox, as it currently does not support the `DNR.setExtensionActionOptions` method. Other than the above issues, it does appear uBO is blocking properly with no error reported in the dev console. The adoptedStyleSheets issue though is worrisome, as the cosmetic filtering content scripts were designed with ISOLATED world injection in mind. Being forced to inject in MAIN world (when available) make things a bit more complicated as uBO has to ensure it's global variables do not leak into the page.
2023-04-07 14:19:43 +00:00
"options_ui": {
"page": "dashboard.html"
},
"optional_permissions": [
[mv3] Add support for specific cosmetic filtering Specific plain CSS cosmetic filters are now supported. Cosmetic filtering will occur only after the user explicitly grant uBO extended permissions for a given site, so that it can inject CSS on the site. A new button in the popup panel allows a user to grant/revoke extended permissions to/from uBO Lite for the current site. More capabilities will be carefully added for when extended permissions are granted on a site, so specific cosmetic filtering through plain CSS is the first implemented capability. Generic and procedural cosmetic filtering is not implemented. The current implementation for plain CSS cosmetic filters is through declarative content injection, which does not require the service worker to be alive, the browser takes care to inject the cosmetic filters. However declarative CSS injection does not support user styles, so the injected cosmetic filters are "weak". I consider this is a browser issue, since user styles are supported by Chromium, there is just no way in the API to specify user styles for the injected content. Also: - Fixed dark theme issues - Added Steven Black's hosts file Keep in mind all this is very experimental and implementation details in this release may (will) greatly change in the future.
2022-09-15 17:14:08 +00:00
"<all_urls>"
],
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
"permissions": [
Add per-site on/off switch to mv3 experimental version
2022-09-07 14:15:36 +00:00
"activeTab",
[mv3] Add support for specific cosmetic filtering Specific plain CSS cosmetic filters are now supported. Cosmetic filtering will occur only after the user explicitly grant uBO extended permissions for a given site, so that it can inject CSS on the site. A new button in the popup panel allows a user to grant/revoke extended permissions to/from uBO Lite for the current site. More capabilities will be carefully added for when extended permissions are granted on a site, so specific cosmetic filtering through plain CSS is the first implemented capability. Generic and procedural cosmetic filtering is not implemented. The current implementation for plain CSS cosmetic filters is through declarative content injection, which does not require the service worker to be alive, the browser takes care to inject the cosmetic filters. However declarative CSS injection does not support user styles, so the injected cosmetic filters are "weak". I consider this is a browser issue, since user styles are supported by Chromium, there is just no way in the API to specify user styles for the injected content. Also: - Fixed dark theme issues - Added Steven Black's hosts file Keep in mind all this is very experimental and implementation details in this release may (will) greatly change in the future.
2022-09-15 17:14:08 +00:00
"declarativeNetRequest",
[mv3] Fix issue with updateContentScripts API and other fixes Avoid using updateContentScripts() as it suffers from an unexpected behavior, causing injected content scripts to lose proper order at injection time. The order in which content scripts are injected is key for uBOL content scripts. Potential out of order injection was causing cosmetic filtering to be broken. Use actual storage API to persist data across service worker wake-ups and browser launches. uBOL was trying to avoid using storage API, at the cost of somewhat hacky code (using DNR API to persist settings). Make use of session storage if available, to speed up initialization of waking up the service worker (which at this point is necessary to properly implement cosmetic filtering).
2023-06-05 13:15:59 +00:00
"scripting",
"storage"
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
],
Rename to less controversial name
2022-09-11 21:41:24 +00:00
"short_name": "uBO Lite",
[mv3] Allows for revisions distinct from filter lists revisions
2023-06-11 14:29:05 +00:00
"version": "1.0",
[mv3] Add support for redirect= filters This adds support for `redirect=` filters. As with `removeparam=` filters, `redirect=` filters can only be enforced when the default filtering mode is set to Optimal or Complete, since these filters require broad host permissions to be enforced by the DNR engine. `redirect-rule=` filters are not supported since there is no corresponding DNR syntax. Additionally, fixed the dropping of whole network filters even though those filters are still useful despite not being completely enforceable -- for example a filter with a single (unsupported) domain using entity syntax in its `domain=` option should not be wholly dropped when there are other valid domains in the list.
2022-10-16 16:05:24 +00:00
"web_accessible_resources": []
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: 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. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 17:47:52 +00:00
}
Reference in a new issue Copy permalink