Hacker News Reader

Comment by orf | Hacker News Reader

I don’t get why we need only a declarative manifest format to specify blocking rules.

Chrome has the ability to run code in a sandboxed environment with no external network access. This could be done in JS, or it could be WASM.

So, why can’t they leverage that? Ublock receives the page being visited and it needs to return an array of elements to block. The browser can do the replacement and element stripping itself. This is the approach Safari takes on iOS for content blocking extensions.

Instead, Chrome went with a “limited set of static patterns in JSON format” approach, which rules out or limits a lot of use cases.

But… why? The obvious answer is because they don’t want adblockers, but this seems a bit too obvious. Is there some technical reason I’m missing for this?

View on HN

Sometimes the obvious answer that the ad company wants to limit its browser's ability to block their revenue stream really is the correct one. The technical reasons they've given have all been clearly working backwards to find justifications.

Exactly correct. The advertising company doesn’t want unlimited ad blocking on their ad driven browser.

Googles brand is becoming more and more toxic, from my perspective.

for those looking to switch to firefox (as I did) do be warned that although I make no claim as to whether its more nor less evil than google, firefox does have various ad-related perks sometimes turned on by default... sometimes turned on suddenly with an update a la windows. Firefox in theory lets you cut it all out, but just expect that cutting is needing to be done to get there

Recommend tabs being one of them. Hadn't noticed it until recently when it started recommending Facebook. Yuck.

Thankfully you can turn it off.

This is starting to make what MS did in the 90s look tame by comparison. Google need to be broken up.

It sure is awfully convenient that MV3 by design will prevent referal-stripping extensions

https://github.com/w3c/webextensions/issues/302

(By the way, the meeting minutes are all published so you can read exactly how they're conspiring to kill your privacy and security. Take note of how many times they decide not to implement something citing that they don't want to engage in a cat-mouse game. How benevolent of them, to make the hard decisions on our behalf.)

> Ublock receives the page being visited and it needs to return an array of elements to block. The browser can do the replacement and element stripping itself. This is the approach Safari takes on iOS for content blocking extensions.

> Instead, Chrome went with a “limited set of static patterns in JSON format” approach, which rules out or limits a lot of use cases.

You're incorrect about Safari content blockers, which also use a limited set of static patterns in JSON format. It's basically the same approach as Chrome's Declarative Net Request. (By the way, I'm the developer of a Safari content blocker, as well as a number of browser extensions.)

"A look inside the BPF verifier [lwn]" https://news.ycombinator.com/item?id=41135371

eBPF: https://en.wikipedia.org/wiki/EBPF

"How are eBPF programs written?" https://ebpf.io/what-is-ebpf/#how-are-ebpf-programs-written :

> In a lot of scenarios, eBPF is not used directly but indirectly via projects like Cilium, bcc, or bpftrace which provide an abstraction on top of eBPF and do not require writing programs directly but instead offer the ability to specify intent-based definitions which are then implemented with eBPF.

> If no higher-level abstraction exists, programs need to be written directly. The Linux kernel expects eBPF programs to be loaded in the form of bytecode. While it is of course possible to write bytecode directly, the more common development practice is to leverage a compiler suite like LLVM [clang] to compile pseudo-C code into eBPF bytecode

WASM eBPF for adblocking

My recall is the arguments were as much about performance as security. DNR was complaining that some sites would do bad things during processing & be slow. So, oh, sorry, no one gets features.

It's interesting to see the comparison list of ublock origin vs lite, V2 vs v3/DNR. Has DNR improved what it offers in any marked way since initially "proposed". https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...

If we take WASM as an example, you could strictly bound the number of instructions executed for a given request in order to keep things performant.

I’m not clear on what “bad things” they wheee imagining though?

Honestly, Google is not even wrong to push this. I absolutely want to minimize the amount of untrusted arbitrary code the browser is executing.

It just happens that uBlock Origin is so important and trusted it should be an exception. Those nifty declarative manifest rules should apply to all extensions except uBlock Origin. Actually uBlock Origin should get even deeper access to the browser than it already has.

Truth is software like uBlock Origin should be literally integrated into the browser itself. Just like how every browser contains pop up blockers, they should have extensive content filtering capabilities. The only reason this is not the case is the inherent conflict of interest in an ad company maintaining an ad blocker.

This is not about security, this is about Google trying to place ads. There is no technical reason at all.

Reply on news.ycombinator.com