HN user

gorhill

4,961 karma

https://github.com/gorhill

Posts5
Comments621
View on HN

Best is to report the issue using the "Report an issue" in the popup panel while on Reddit site. There could be other issues causing this, for instance if you didn't grant uBOL the permission to inject scripts on the site. Depending on which browser/os the issue occurs, we should be able to narrow down potential causes.

I never transferred the extension in the Chrome store. The Chrome store extension has always been the one from the repository I control, and I've had full control of it since when I created it back in June 2014.

When trying to diagnose performance or memory issues with a browser, always start with the installed and enabled extensions.

it claims to use zero CPU

There is no claim of "zero CPU". The claim is that the service worker wakes up only when necessary -- it is designed to be suspended by default from the ground up.

In Optimal and Complete modes, the content scripts will of course execute, without the service worker being unsuspended if no filtering occurs, but perform only the necessary work and bail out ASAP if not needed.

In Basic or "No filtering" modes, no content scripts are injected.

---

Edit: Sorry, I do say "uBOL itself does not consume CPU/memory resources while content blocking is ongoing". When I say "itself" I am referring to the service worker as seen in Chromium's Task Manager. The service worker isn't required for examples when navigating to `example.com` or here at `news.ycombinator.com`. All top content blockers I have looked at do require their service worker to execute, even for merely just switching between tabs. Some even use tricks to prevent their service worker to be suspended at all.

When you enable "Developer mode" in the "Extensions" page of your browser, you can open the developer tools for the extension by clicking the "service worker" link, and from there select the "Network" tab, you will be able all the network requests made by the extension from within its service worker.

No competent content blocker tests "ten thousand regexp matches" for each request URL to match, this is not how it works.

To simplify, and speaking from uBO's perspective, consider that nine distinct tokens can be extracted from the URL in the address bar for the current webpage:

  https
  news
  ycombinator
  com
  reply
  id
  41758007
  goto
  item%3Fid%3D41757178%2341758007
To match such URL against the tens of thousand of filters, there is only a need to lookup filters for these nine tokens, and for most of these tokens there won't be any filters to test, such that in the end for any given URL only a few to no filters will end up being tested, and the majority of these filters are not regex-based, they are just plain string matching.

This is the overall simplified explanation of how it really works, in reality it's a bit more complex because there are a lot of other optimizations on top of this.

There is a built-in benchmark tool in uBO, accessible through the dashboard, _Support_ pane, _More_ button, _SNFE: Benchmark_ button[1].

When running the benchmark against a set of 230,364 URLs, I get an average of 11-12 µs per request to perform a match test against the default filter lists in uBO.

* * *

[1] https://github.com/gorhill/uBlock/wiki/Advanced-settings#ben...

The extension in the Chrome Web Store (CWS) never changed hands. I just reverse-forked a GitHub repo, which was of no consequences to those who installed the extension from the CWS. I was asked to transfer the CWS entry, I refused. This can't be compared to an extension changing hands or going rogue in the CWS.

It's perfectly fine and valid to question the pile of JS code executing in Youtube webpages, but in this specific instance the performance issues are caused by ABP/AdBlock. The issue has been acknowledged by the developers[1]. It affects only the latest version of both blockers, not previous versions, so it makes no sense to keep speculating Google is at the root of that specific issue.

Out of curiosity I investigated these performance issues myself using profiling sessions[2] and the faulty code is definitely in the latest versions of these extensions.

* * *

[1] https://gitlab.com/adblockinc/ext/adblockplus/adblockplusui/...

[2] https://twitter.com/gorhill/status/1746543688975581604

It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”.

It's not just about cosmetic rules, it's also about DNR rules other than block/allow/allowAllRequest: redirect=, removeparam=, csp=, etc.

If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.

If these DNR rules are considered potentially harmful thus requiring thorough reviews, why would they be allowed to be downloaded from a remote server and dynamically created in the first place?

There is also the content scripts-based filters, which is something that change every day. This is where we diverge, I chose to go fully declarative because this way these content scripts are injected reliably in a timely manner by the MV3 API.

This is not the case when injecting in a event-driven manner since the extension's service worker may need to wake up, fully restore its current state, then by the time it's ready to inject the content scripts programmatically, it might be too late as the target webpage has already started to load.

one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year.

My understanding is that no-review-fast-track is only for extensions which changes in DNR rulesets are only about block/allow/allowAllRequests rules.

I don't see how comprehensive content blockers can push meaningful updates with only changes to block/allow/allowAllRequests rules and nothing else.

For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string[1], the content scripts must be part of the package.[2]

There is userScripts API which allows injecting code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API.[3] In Firefox, the documentation for this API has the following note[4]:

When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts

* * *

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

[2] https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium...

[3] https://developer.chrome.com/docs/extensions/reference/userS... ("Availability Pending")

[4] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

This was the first commit, and the commit message is accurate about the technical limitations of this first version.

If you want cosmetic filtering and other advanced filtering in the current, more mature version, you need to explicitly grant host permission for either the site or everywhere.

uBlock to intercept http requests before rendering the web page. And from my understanding this has always been supported in Firefox, but never in Chrome.

The webRequest API does allow to intercept and cancel HTTP requests, it has been part of Chrome extensions API since 2011.

rare minor annoyance of cosmetic filtering (which gorhill removed for political, not technical reasons)

Please clarify.

No political motivation went into uBO Lite. It supports cosmetic filtering just fine -- it's a matter of picking the appropriate filtering mode.

To turn your browser (an agent acting on your behalf) into a proprietary application (an agent acting on behalf of a website) -- i.e. the equivalent of forcing you to install a proprietary application in order to visit a website.

My understanding:

Global warming occurs because the previous equilibrium between incoming and outgoing energy has been broken by changes in the composition of the atmosphere.

So until we reach a new equilibrium long after the atmosphere composition ceases to change, the outgoing energy will be less than the incoming energy.