uBlock origin in ladybird
I assume ladybird does not yet have an extension platform for people to install add-ons, such as uBlock origin.
Recently Google went in to take down uBlock origin - see websites such as https://www.indiatoday.in/technology/news/story/using-ublock-origin-google-chrome-warns-users-it-is-going-to-ban-it-2577055-2024-08-05 but of course others (that one is just an example of many more news site reporting on Google's strategy right now. Of course they claim that Manifesto 3 is a change in general, but let's be brutally honest: they specifically want to get rid of ad-blocking, since this threatens their business model the most - the rest is just Google trying to disguise that).
The recommendation by the uBlock origin to move to Firefox does not work, IMO, because Firefox gave up the fight a long time ago already; got addicted to the influx of Google money, and also started to track users not too terribly long, so for me, I don't trust Firefox either. I am actually using thorium, so I succumbed to the Google Empire, as there are no more alternatives. Dictatorship now controls the world wide web. Which browser is going to stand up against any of that? Perhaps ladybird may be one day, but who knows. But anyway, back to the main topic (and this issue can be closed, no problem, it is more to start a bit of thoughts and discussions, specifically in regards as to what ladybird aims to achieve, for users.)
Obviously for any alternative, one needs to find a way that it remains truly open, rather than semi-open as Firefox (any organisation that tracks users, can not be trusted, in particular when it becomes addicted to influx of money from corporations, aka bribes).
So, narrowing these thoughts down more specifically for ladybird:
(1) Are there plans for ladybird to support extensions? If so, how? (I guess in the simplest way, the question is how user-content could be delivered via custom javascript code, which kind of satisfies at the least one part of an extension ecosystem; obviously another one would be how people can download these extensions, if there is anyone doing monitoring of it or will it end up as left-pad-2.0)
(2) Specifically in regards to blocking content (which can also happen outside of extensions, of course): does ladybird have any plans or strategy to handle a user wanting to specifically NOT see certain content? I refer to this in general, not just anti-ad blocking. People may, for whatever the reason they have, block more content. For instance, kiosk mode in a university campus site, may require different settings than a user at home on a classical desktop computer system. (Usually kiosk mode is more restricted in many ways.)
- No plans, other than "we want extensions eventually". There's a very rough WebExtensions spec, I believe based on how the other browsers' extensions work, which I assume we'll follow. But the focus for now is just on making the browser run the web well.
- We have basic ad/tracker blocking built in. Otherwise, no plans but that sounds like something that can be done with extensions.
I support extensions and adblocking as a critical part of web browser security and fully agree that it needs improved, and would like to see ad blocking fully supported in the API for extensions.
I support adblocking in LadyBird, as I consider the ability to block forms of malicious advertisements to be a critical security issue because advertisements often include hostile JavaScript. Advertisers are often malicious, so we need to consider fingerprinting as well as sites that try to weaken CORS through third party scope grants that then inject JavaScript that does bad things.
The best thing in my mind is if we can control how specific domains are handled on a domain or even TLD level based on the DNS tree supporting simple ? and * simple regex semantics. If the third party domain artificially returns a 404 for example, that might be best depending on user choice. Or maybe instead of returning anything it just returns the reply ladybird configures for the domain based on user choice. Then we have plugins configure that based on lists so people can have things like "domains that end in .ru or .cn" are not allowed" for enterprise compliance while doing things like "domains at ,test. cant load JavaScript.
For example maybe the security system doesn't allow a specific domain to load JS at all.
Maybe another domain is only allowed to load images or another only text files.
But to do that we need a robust pipeline that can be configured. The ability to block ads also means that from a security and compliance perspective, it will be easier for companies to support on their corporate network.
The best thing in my mind is if we can control how specific domains are handled on a domain or even TLD level based on the DNS tree supporting simple ? and * simple regex semantics
Please have a look at the existing denylist code and data here:
https://github.com/LadybirdBrowser/ladybird/blob/d755a83c09a5fba82a91f9cc3f9e3b2e07880127/Userland/Libraries/LibWeb/Loader/ContentFilter.cpp
https://github.com/LadybirdBrowser/ladybird/blob/d755a83c09a5fba82a91f9cc3f9e3b2e07880127/Base/res/ladybird/default-config/BrowserContentFilters.txt
This feature has been in the browser since January 2021 https://github.com/LadybirdBrowser/ladybird/commit/a6d52e0c97df3b714b2077ed676e84c6513dbf15.
No plans, other than "we want extensions eventually". There's a very rough WebExtensions spec, I believe based on how the other browsers' extensions work, which I assume we'll follow. But the focus for now is just on making the browser run the web well.
- We have basic ad/tracker blocking built in. Otherwise, no plans but that sounds like something that can be done with extensions.
One thing to add about this, if I may: Firefox, even before the polemics regarding the newest manifest version and the termination of adblocking on Chromium browsers, has had a notably wider range of allowances in regards to what an extension is allowed to do. I mention this because I much enjoy the Tridactyl extension on Firefox, which allows one to have vim-like controls just about anywhere in the browser. This kind of extension exists on Chromium as well, but it is more annoying to use precisely, I assume, because of the restrictive nature of Chromium itself in regards to them. So this is something to consider, as I'm sure it would be great to follow Firefox's example more so than that of the others.
Do forgive my lack of details here. I speak as laity as I do not understand the specifics quite well. This comes from my experience running similar extensions in both the Gecko and Chromium engines, and it seems Gecko comes out strongly on top.
I also think that both intuitive, fine-grained permissions like uMatrix and comprehensive shortcut remapping are critical features. Rather than discussing them as extensions, I think this particular functionality should be tightly integrated.
uMatrix support for local storage and scripts could definitely be enhanced to provide more fine-grained control. For example, expanding a column into rows of individual cookies or scripts. The cookies could display their respective settings and values while the scripts could link to the dev tools viewer. I would also love to see support for whitelisting redirects and WebRTC per domain.
I also think some of the uMatrix functionality should be unnecessary in a better designed web browser. For example, the cookie management options.
On the topic of shortcut management, I use Vimium. The convenience with which I can override it's key mappings per domain is very nice.
Other extensions with functionality I would like to see integrated include:
- Tab Manager Plus
- Custom Scrollbars
- Neat URL
- Quick Sorted Download
The sort of extensions that I think should reasonably remain extensions include:
- ClearURLs
- KeePassXC
- LibRedirect
Firefox has had a notably wider range of allowances in regards to what an extension is allowed to do
In terms of functionality somewhat yes, but they're also more stringent regarding privacy and addons not doing remote loading, collecting data, etc. Manifest v3 is somewhat more restrictive in functionality in general, even ignoring Google's special limitations.
@AtkinsSJ:
Some notes and thoughts on implementing webextensions in a new browser:
I've developed and forked/modified extensions on both browsers. I think implementing / adding Webextensions support into a new browser is non-trivial (if it's robust).
Generally I've found Chromium's Webextensions API to be more consistent and less idiosyncratic, but the interaction between extension controls and the browser chrome is better in Firefox (mainly due to a few longstanding Chrome UI bugs).
One annoying bug in Firefox's implementation that I've encountered is https://bugzilla.mozilla.org/show_bug.cgi?id=1266960
It would be good in a new browser webext implementation to address cases like this up front (and robust testing) so the burden is not on client developers, and there aren't "bugs" or functionality limiting behaviours that live for decades in the codebase.
I think a new implementation should target one API namespace, and not use too many aliases for the same functions or namespace. So probably use chrome.tabs and not browser.tabs for example. One exception to this is if you want "out of the box" compat with existing Firefox addon packages, or Chromium addons that use the 'legacy' namespaces.
I've heard mv3 had better performance, but as a developer (not exclusively focused on extensions or JS), mv2 seemed more straightforward and better documented or intuitive, and mv3 did not have any tangible benefit. However, I understand as mv3 is the current standard, it probably makes sense to support it. Service workers would be something to figure out. I think only Chromium uses service workers, while Firefox mv3 still uses background scripts as of 2024.
I have some examples of basic useful at https://github.com/mv3-examples
Best,
Hi, I'm also an extension developer. I'd disagree that Ladybird should should use the chrome namespace, given that its not chrome. Other browsers, like Safari, use browser and the best existing documentation for the web extension API is on MDN and using browser. There was also an abandoned attempt at a W3 spec that uses browser. Thankfully this is mostly not a problem due to Mozilla's great https://github.com/mozilla/webextension-polyfill
As for whether there are implementations that are non-coherent with each other that is often a bug.
ManfiestV3 is not necessarily inherently better for performance across the board, but because of its strictness in controlling how much execution time a background script has access to can allow browsers to better control performance.
As of now chromium's API is the basis for a lot of Firefox's implementation. But there is a W3C Community Group trying to standardize and eventually make a specification.
really need web extensions support since its a w3c standard now.
really need web extensions support since its a w3c standard now.
If you mean https://w3c.github.io/webextensions/specification/index.html, I assume there's a reason it still has UNOFFICIAL DRAFT plastered all over the background and half of it is rather empty. But I do agree.
I think firefox and chrome both support same web extension version with very minimal tweaks between the two browsers. I think we should add one or the other because A browser with extensions is not something I'm going to use much.
Mainly i use bookmarks sync and ublock and metamask etc.
here's the repo for anyone interested: https://github.com/w3c/webextensions
Better idea, what if adblocking (more generally, content blocking) was built in using native code? Initially, something like uMatrix could be supported, and then uBlock filter lists and automatic filter list updating could be added later.
Doing this would allow good content blocking to be added as an easy, out of the box feature (w/ uBlock filters as default because they are default-allow), and would also allow it to be added before WebExtensions are supported.
Brave has a great rust based adblocker. I think it should be pasted into ladybird if possible.
Better idea, what if adblocking (more generally, content blocking) was built in using native code? Initially, something like uMatrix could be supported, and then uBlock filter lists and automatic filter list updating could be added later.
Doing this would allow good content blocking to be added as an easy, out of the box feature (w/ uBlock filters as default because they are default-allow), and would also allow it to be added before WebExtensions are supported.
I disagree, I like what firefox is doing were they have their own basic lists and I use ublock origin to enhance it. Ladybird having a built-in ad blocker would be nice but that won't solve the issue where for most people extensions like ublock origin and umatrix and bitwarden/keepassxc are a must (ViolentMonkey as well) I don't think it's smart to focus on integrating them into native code when extensions already exist.
Ladybird also already has a basic tracker list built-in for blocking?