4 ms·

What if we implemented ublock origin in native code from Browser's side instead of implementing it as extension? Will there be performance, efficiency and memor

What if we implemented ublock origin in native code from Browser's side instead of implementing it as extension? Will there be performance, efficiency and memory improvements?

seanw444 3y ago
The answer is almost certainly yes. But I wonder if the APIs it uses are already fast enough that doing so would yield negligible benefits?
brucethemoose2 3y ago
Yes, see https://github.com/uazo/cromite https://github.com/uazo/cromite But the history of minimalistic Chromium forks is kinda sad, as they seem to get little attention and maintaining them requires a ton of work. They tend to burn out, like the dev of Bromite did.
pvg 3y ago
That's more or less the goal of DeclarativeNetRequest in Chrome/manifest v3 and similar facilities in Safari.
- dewey 3y ago
  I somehow doubt the goal of the people behind Chrome is to make ad-blocking performance better.
  - scq 3y ago
    That is their stated goal. > There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers. This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers. -- https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ...
    - wtallis 3y ago
      Implementing DeclarativeNetRequest is mostly about making (simple) blocking perform better. Instituting unrealistically low limits on the number of rules that can be registered is not; if anything, the new APIs should have been enabling much larger filter lists than are currently in widespread use through the old APIs.
  - pvg 3y ago
    It's not a particularly difficult thing to assess technically.
  - deprecative 3y ago
    As Google is an ad company, anyone believing that they want to make ad-blocking better is.. not looking at the economics. What makes sense if this is what they're pushing forward with is that Google sold ads would be exempted while other ads would be ground out. My guess is there's a mix of reasons and none of them are for the benefit of the users.
- stonogo 3y ago
  It achieves "efficiency" by dropping functionality and limiting rule counts. There are mitigations. Extensive discussion here: https://github.com/uBlockOrigin/uBlock-issues/issues/338 https://github.com/uBlockOrigin/uBlock-issues/issues/338
yjftsjthsd-h 3y ago
I think Brave claims to be doing something like that?
dharmab 3y ago
Orion blocks ads natively and also supports adblock extensions: https://blog.kagi.com/orion-features https://blog.kagi.com/orion-features

What if we implemented ublock origin in native code from Browser's side instead of implementing it as extension? Will there be performance, efficiency and memory improvements?

seanw444 3y ago

The answer is almost certainly yes. But I wonder if the APIs it uses are already fast enough that doing so would yield negligible benefits?

brucethemoose2 3y ago

Yes, see https://github.com/uazo/cromite https://github.com/uazo/cromite But the history of minimalistic Chromium forks is kinda sad, as they seem to get little attention and maintaining them requires a ton of work. They tend to burn out, like the dev of Bromite did.

pvg 3y ago

That's more or less the goal of DeclarativeNetRequest in Chrome/manifest v3 and similar facilities in Safari.

dewey 3y ago
I somehow doubt the goal of the people behind Chrome is to make ad-blocking performance better.
- scq 3y ago
  That is their stated goal. > There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers. This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers. -- https://blog.chromium.org/2019/06/web-request-and-declarative-net-request.html https://blog.chromium.org/2019/06/web-request-and-declarativ...
  - wtallis 3y ago
    Implementing DeclarativeNetRequest is mostly about making (simple) blocking perform better. Instituting unrealistically low limits on the number of rules that can be registered is not; if anything, the new APIs should have been enabling much larger filter lists than are currently in widespread use through the old APIs.
- pvg 3y ago
  It's not a particularly difficult thing to assess technically.
- deprecative 3y ago
  As Google is an ad company, anyone believing that they want to make ad-blocking better is.. not looking at the economics. What makes sense if this is what they're pushing forward with is that Google sold ads would be exempted while other ads would be ground out. My guess is there's a mix of reasons and none of them are for the benefit of the users.
stonogo 3y ago
It achieves "efficiency" by dropping functionality and limiting rule counts. There are mitigations. Extensive discussion here: https://github.com/uBlockOrigin/uBlock-issues/issues/338 https://github.com/uBlockOrigin/uBlock-issues/issues/338

yjftsjthsd-h 3y ago

I think Brave claims to be doing something like that?

dharmab 3y ago

Orion blocks ads natively and also supports adblock extensions: https://blog.kagi.com/orion-features https://blog.kagi.com/orion-features