-
Notifications
You must be signed in to change notification settings - Fork 187
Justification for the declared permissions
To change the filtering mode for the current website, including toggling the content blocker on and off.
To execute low-priority housekeeping tasks, such as pruning least-recently used cosmetic filters from session-based cache or clearing expired cached data from subscribed remote filter lists.
To declaratively tell the browser which network requests to block, not block, redirect, or — in some cases — modify.
An offscreen document is used as a replacement for dynamic import, which isn't possible inside a service worker. This keeps the service worker lean by avoiding loading JS code that's needed only intermittently — when the user opts to create their own filters or explicitly subscribes to filter lists hosted on remote servers.
The offscreen document is used to execute code which parses and compiles the user's own filters or subscribed filter lists, keeping the service worker as lean as possible when there's no need to parse and compile filters and/or filter lists. If the explicitly subscribed filter lists aren't cached locally, they'll be fetched from their respective remote servers from within the offscreen document.
The reason parameter used is "WORKERS" even though the offscreen document doesn't use a worker -- I couldn't find a better matching value. In effect, the offscreen document itself acts as a service worker spun up by the extension's actual service worker when needed.
To be able to declaratively inject CSS/JS content scripts for better content filtering on various sites requiring more advanced content filtering than what the DNR API alone can provide.
storage.local: To persist user settings and data across browser launches.
storage.session: To speed up service worker initialization time by persisting mutable data always required by the service worker.
Since users can explicitly subscribe to filter lists hosted on remote servers, the extension must have enough storage to cache the results of parsing and compiling these subscribed filter lists locally for efficiency. This avoids having to fetch, parse, and compile them every time the user changes which filter lists are enabled.
For chunks of data containing data structures that aren’t JSON-compatible, a serializer/deserializer is used to convert to and from Unicode strings, optionally with compression for large data structures.
To allow user to create their own user custom filters, or to explicitly subscribe to filter lists hosted on remote servers. Custom filters and filter lists are compiled into dynamic DNR rules (network-based filters) and declaratively injected user scripts (cosmetic- and scriptlet-based filters).
The scriptlet-based filters crafted by the user or imported from subscribed filter lists hosted on remote servers are always limited to an existing library of code snippets packaged in the extension's /js/resources/ directory.
Official documentation for scriptlets is under "Scriptlet injection" at: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#scriptlet-injection
By default, uBO Lite is intended to filter content everywhere more effectively. The extension can still be used with reduced host permissions if the user chooses so.
https://github.com/uBlockOrigin/uBOL-home.wiki.git
this is open to everyone