Something is different in the arms race this time.
Browser development is almost exclusively funded by advertising. Chrome, in the obvious way. Mozilla is funded entirely by Google. Safari is the only surviving exception.
Browser development is almost exclusively funded by advertising. Chrome, in the obvious way. Mozilla is funded entirely by Google. Safari is the only surviving exception.
Have you tried 1Blocker X?
Though, for fun, I've rolled my own Safari extension for content blocking. You get 90%+ of the way just concatenating lists of ad domains and feeding them into the blocker. But, for example, you can encode all of Easylist as content-blocker rules.
I think the ideal system would support declarative and non-declarative modes (since a fully declarative system could never account for every possible use case).
And there's no pressure from users to choose the more restrictive but performant option because people basically have zero insight into what's killing their battery, much less which competitor is better in that regard.
Given the gulf between Safari vs Chrome battery performance, I'm not all that convinced that the declarative api is pure downside like HN cynicism and Twitter outrage might suggest.
I can agree that it would be nice to have competing implementations, but that's just the result of browsers being so complex that once your hobby horse feature is removed from one, you basically have nowhere to turn.
Safari was already beating Chrome on battery life before its extension API was neutered. This is post hoc revisionist rationalization.
It could also be that because of the reduced expressiveness of the adblocker, more ads are missed, and you might therefore end up with a net increase in the amount of code that has to be executed by the browser. So the declarative API could actually lead to a performance decrease in practice.
> In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible.
> As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses.
You are free to dismiss the writeup as lies, of course. You're also free to handwave it away by saying "well I don't like the trade-off". But you can't discuss this as if the benefits are not apparent.
[1] https://blog.chromium.org/2019/06/web-request-and-declarativ...
Furthermore here you can see a tweet from Justin Schuh, lead of security and privacy on Google Chrome, where he claims that the "sole motivation is correcting privacy and security deficiencies" (which I just debunked as being a possibility), not performance: https://twitter.com/justinschuh/status/1134092257190064128
So between Justin Schuh and Simeon Vincent (author of the post you linked), who is lying? It must be at least one of them.
But let's ignore the misleading claims about security/privacy and just focus on the performance issue.
In this post, they include absolutely no numbers or measurements of the performance effects of using the content blocking API. They give some explanation of what is technically required to implement each approach, and certainly the declarative API is a simpler approach, but you made that point already. And I responded to it. Just because the API is "obviously simpler" doesn't mean the performance advantage is in any way significant, and could even be outweighed by the increased ad load due to the less powerful API. It's just not at all obvious from what they are saying here that the change is worth compromising user functionality over.
If you want a source with actual measurements, you should check the Ghostery team's response to the manifest v3 changes: https://whotracks.me/blog/adblockers_performance_study.html
Here are some highlights:
> All content-blockers except DuckDuckGo have sub-millisecond median decision time per request.
> Time to Process a Request in Ghostery (median): 0.007 ms
> Loading Ghostery's Blocking Engine (from cache): 0.03 ms
> Memory Consumption of Ghostery's Blocking Engine (at startup, in Chrome): 1.8 MB
Note that last one: 1.8 MB memory consumption. And they're arguing that we need to be "setting up and tearing down this component as needed" to conserve that "valuable" 1.8 MB. Nonsense.
> That's because they have explicitly stated that they will not deprecate the observational webRequest API, which has exactly the same privacy considerations as the content blocking API.
It's still a substantial improvement if popular extensions that don't need to use observational webRequest (ie. content blockers) no longer use this more expensive method. It's a leap of logic to suggest that supporting observational webRequest means that the simpler content blocking API has no benefit.
> Furthermore here you can see a tweet from Justin Schuh, lead of security and privacy on Google Chrome, where he claims that the "sole motivation is correcting privacy and security deficiencies" (which I just debunked as being a possibility), not performance (...) So between Justin Schuh and Simeon Vincent (author of the post you linked), who is lying? It must be at least one of them.
Neither. The change may be motivated by privacy and security but as Simeon Vincent explains, it also has substantial performance benefits. I'm not sure how you logically leap to the conclusion of "this has no performance benefits" from "we did this for privacy/security reasons".
It's also extremely misleading to compare the performance of a content-blocked site to internal browser performance. You know what has the best overall performance? An extension that blocks the whole page; 0ms speed, the best performance, almost zero battery drain, except that this hypothetical extension consumes substantial resources on its own. But hey, the 0ms page speed makes up for it. It'd be pretty silly for the Chrome team to base their decisions on the performance of rendering an incomplete webpage depending on both random extension makers and random website creators.
> Note that last one: 1.8 MB memory consumption. And they're arguing that we need to be "setting up and tearing down this component as needed" to conserve that "valuable" 1.8 MB.
Ghostery is only one extension among them, and all the adblocking extensions in that performance study ran a pre-pruned set of EasyList rules when popular adblockers run more rules in practice.
I think the solution is a new web protocol that does not require an OS in a box (browser). It will be supported by decentralized (mostly p2p) protocols. It probably will not have any JavaScript.
Attached applications could be web assembly with I/O abilities such as a simple canvas-like UI.
If you can find or create a suitable and high performance p2p system (or group of systems) for enabling people to load and publish these lightweight links, you could provide a useful and viable alternative to the traditional web that would be approachable by small development teams.
Built in p2p search could be a killer feature for such a system.
EDIT: made a github for it and submitted to HN https://news.ycombinator.com/item?id=20544892
(I'm admittedly not sure how I'd classify stuff like Pale Moon, which is primarily based off someone else's engine but now backports its own patches.)
Brave already integrates ad-blocking at a lower level than the webRequest API, so this is less of an issue, but you sacrifice your choice in blocker.
https://brave.com/improved-ad-blocker-performance/
The recent Chromium’s Manifest v3 controversy around the overheads of the various extensions using the WebRequest API to inspect and potentially block undesired requests did not affect Brave as requests are processed natively, deep within the browser’s network stack.
What I find much more scary is the prospect of the entire web stack becoming much more locked down as a consequence of both (1) ad blocker prevention and (2) the consolidated browser market. Think Encrypted Media Extensions, but for everything.
If there were ten browsers in active use today, getting them all to agree to something like this would be almost impossible. Unfortunately, there's only 2–3 browsers, and if Firefox loses any more marketshare...
Do you have a source for that?
> Mozilla Foundation philanthropic programs and activities are funded by public support from individual donors and foundations ($13.8M), as well as from royalties earned that are paid by the Mozilla Corporation ($8.3M). Total revenue and income support to the Mozilla Foundation in CY 2016 was $23.4M.
> The majority of Mozilla Corporation’s revenue is from royalties earned through Firefox web browser search partnerships and distribution deals around the world. Mozilla Corporation’s revenue and income support for CY 2016 was $506M
https://www.computerworld.com/article/2500712/google-to-pay-...
> Google to pay Mozilla $300M yearly in new search deal, says report