Awesome Privacy

Recent Commits

• Raymond Hill (14 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (14 Sept 24)

  New revision for dev build

• Raymond Hill (14 Sept 24)

  Fix regression re. `mp4` filter option Related issue: https://github.com/uBlockOrigin/uBlock-issues/issues/3375

• Raymond Hill (13 Sept 24)

  Use dummy dns API when it's not present

• Raymond Hill (13 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (13 Sept 24)

  New revision for dev build

• Raymond Hill (13 Sept 24)

  Code review of DNS-related code Related commit: https://github.com/gorhill/uBlock/commit/6acf97bf5143543c036c38a82160e5f8efe8b3f1

• Raymond Hill (12 Sept 24)

  Import translation work from https://crowdin.com/project/ublock

• Raymond Hill (12 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (12 Sept 24)

  New revision for dev build

• Raymond Hill (12 Sept 24)

  Update changelog

• Raymond Hill (12 Sept 24)

  Rewrite cname uncloaking code to account for new `ipaddress=` option This commit makes the DNS resolution code better suited for both filtering on cname and ip address. The change allows early availability of ip address so that `ipaddress=` option can be matched at onBeforeRequest time. As a result, it is now possible to block root document using `ipaddress=` option -- so long as an ip address can be extracted before first onBeforeRequest() call. Related issue: https://github.com/uBlockOrigin/uBlock-issues/issues/2792 Caveat ------ the ip address used is the first one among the list of ip addresses returned by dns.resolve() method. There is no way for uBO to know which exact ip address will be used by the browser when sending the request, so this is at most a best guess. The exact IP address used by the browser is available at onHeadersReceived time, and uBO will also filter according to this value, but by then the network request has already been sent to the remote server. Possibly a future improvement would make available the whole list of ip addresses to the filtering engine, but even then it's impossible to know with certainty which ip address will ultimately be used by the browser -- it is entirely possible that the ip address used by the browser might not be in the list received through dns.resolve().

• Raymond Hill (11 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (11 Sept 24)

  New revision for dev build

• Raymond Hill (11 Sept 24)

  Code review for `ipaddress=` filter option If an IP address can be extracted from the hostname portion of a URL, the IP address matching will be performed at onBeforeRequest() time. Regardless, IP address matching will subsequently always be performed at onHeadersReceived() time as the request details at that point contain a reliable IP address value on supported platforms (Firefox- only as of now). The `cap_ipaddress` now evaluates to `true` in Chromium-based browsers. Even though these browsers are unable to provide reliable IP address value at onHeadersReceived() time, they can still perform IP address matching for IP address extracted from hostname portion of a URL.

• Raymond Hill (10 Sept 24)

  Update changelog

• Raymond Hill (10 Sept 24)

  Avoid using dns.resolve() for proxied DNS resolution Related issue: https://github.com/uBlockOrigin/uBlock-issues/issues/1743

• Raymond Hill (10 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (10 Sept 24)

  New revision for dev build

• Raymond Hill (10 Sept 24)

  Update changelog

• Raymond Hill (10 Sept 24)

  [mv3] Mind unsupported `header=`/`ipaddress` options in DNR API Properly report unsupported `header=` and `ipaddress=` option in log file. `header=` support may become possible soon with Chromium 128 introducing blocking according to response headers content.

• Raymond Hill (10 Sept 24)

  Add support for `lan`/`loopback` values to `ipaddress=` option Related issue: https://github.com/uBlockOrigin/uBlock-issues/issues/1070

• Raymond Hill (09 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (09 Sept 24)

  New revision for dev build

• Raymond Hill (09 Sept 24)

  Properly reflect whether `ipaddress=` is supported

• Raymond Hill (09 Sept 24)

  Make Firefox dev build auto-update

• Raymond Hill (09 Sept 24)

  New revision for dev build

• Raymond Hill (09 Sept 24)

  Update changelog

• Raymond Hill (09 Sept 24)

  New static network filter option `ipaddress=` The purpose is to block according to the ip address of a network request. In the current implementation, the filter option can only be enforced at onHeadersReceived time. The new filter option cannot be enforced in Chromium-based browsers since the ip address of network requests is available only at onResponseStarted time, which is not blocking. The value assigned to `ipaddress` can either be a plain string which must match exactly a given ip address, or a regex which will be matched against the ip address. The `ipaddress` option can only be enforced when the extension framework does provide a valid ip address in a onHeadersReceived listener. For instance, cached resources do not have a valid ip address and thus can't be a match to `ipaddress` option. Example: *$script,ipaddress=93.184.215.14

• Raymond Hill (08 Sept 24)

  Add ability to quote static network option values For the sake of convenience for filter list maintainers, this commit add ability to quote static network option values, so as to avoid the need to escape commas when parser ambiguity arises. The quotes can be `"`, `'`, or backticks. Example, the following filter requires escaping commas: example.com$xhr,replace=/"loremIpsum.*?([A-Z]"\}|"\}{2\,4})\}\]\,//,1p Can be now rewritten with no need to escape when using quotes: example.com$xhr,replace='/"loremIpsum.*?([A-Z]"\}|"\}{2,4})\}\],//',1p