I'm fairly happy with uBlock Origin Lite. Sure the original was better but this one does the job as well. uBlock Origin Lite is a MV3 extension, by the same author.
https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as... has a few of the more practical concrete examples. Namely content can load without the blocker being ready to filter, CNAME cloaking can't be handled properly (in Chrom* at least), and the filter rules aren't as flexible.
Interestingly, the rule count limits themselves do not (currently) seem to be much an issue despite it being one of the more common concerns on the original MV3 announcement.
> content can load without the blocker being ready to filter
This isn't an MV3 issue, it's a Chromium design decision that extensions cannot block browser initialization. It was also true with MV2. In fact, MV3 has improved the situation because DNR rules are enforced immediately.
You could certainly argue that Chrome should allow extensions to block browser initialization, or that it should be user configurable - but it seems like an entirely defensible Chrome decision. Regardless, it's nothing to do with MV3.
> the filter rules aren't as flexible.
That's true, but they are still very flexible, and DNR makes some very nice features possible in uBO lite that were not possible in uBO.
For example, did you know that you can change your User-Agent with uBO lite? Go to the Custom DNR rules tab, and enter something like this to pretend to be Lynx on whatever.com:
Any MV3 issue could probably be summed up as "MV3 isn't so bad, just the implementation in Chrome" where Chrome defines MV3 (as it's not a W3C standard) and ships it as such.
That said,
> Chromium design decision that extensions cannot block browser initialization
It's not "browser initialization" that was blocked, it was blocking network requests for pages until they were processed by all components in the chain. Notably, this could never apply applied to the browser or its internal pages itself.
Firefox is a great example about all of the above points: MV3 still supports blockingWebRequest there, so it gets the best of both worlds.
> did you know that you can change your User-Agent with uBO lite?
With MV2 you'd use blocking webRequest and chrome.webRequest.onBeforeSendHenders. I'm not sure uBO ever bothered with this before uBO Lite, but it's a bit of a double standard to say "MV2 didn't offer blocking requests, that was a different API which happ
> and then the request had to wait until it was given to and processed by the blocker.
Despite the name, the requests were not blocked until the extension had initialized. The browser could make network requests before that happened with MV2. With MV3, static rulesets and persistent DNR rules are enforced immediately.
> With MV2 you'd use blocking webRequest and chrome.webRequest.onBeforeSendHenders
Of course an extensions could do this, I said uBO lite. DNR made exposing this powerful functionality fast and easy. My point is that MV3 uBO lite has useful features that MV2 uBO does not.
> Despite the name, the requests were not blocked until the extension had initialized. The browser could make network requests before that happened with MV2. With MV3, static rulesets and persistent DNR rules are enforced immediately.
There were several workarounds like suspendTabsUntilReady which helped greatly in this half of the problem. Then it would solidly stay permanently registered too. I'm pretty sure none of these work in Chrome anymore though, it was obvious they never intended these sorts of things to work that way.
Nevertheless, MV3's ability to offer limited filtering on startup does not seem like such a blessing when the other option was to just guarantee full filtering on startup as seen in this change https://bugzilla.mozilla.org/show_bug.cgi?id=1447551
> Of course an extensions could do this, I said uBO lite. DNR made exposing this powerful functionality fast and easy. My point is that MV3 uBO lite has useful features that MV2 uBO does not.
What you said is so, it just might highlight more than what you'd like it to at the same time. That it was missing before had nothing to do with the difficulty or need for MV3. uMatrix had it for a while and Gorhill regretted it because it didn't change things like the user agent JS would report and such, hence he wouldn't port it over. The above filter has the same problems. Great if you just want a normal quality user agent switcher, that it's normal quality is why it was never in the old extension though.
> Nevertheless, MV3's ability to offer limited filtering on startup does not seem like such a blessing when the other option was to just support full filtering on startup
Sure, but as I said, it's a design decision, and nothing to do with MV3. I'm not trying to litigate it one way or the other.
I do think DNR is a good solution, and that request callbacks were a bad idea. That's my opinion - and the counterargument is obvious -- you can't do literally everything you could do in a callback declaratively. That doesn't sway me, I still think it's better!
> Great if you just want a normal quality user agent switcher
It was just a trivial example of using a powerful new feature that uBO doesn't have, not a full featured extension! The fact that it's possible at all is the point, it's cool.
You can definitely do anything that DNR can do with webRequest, nobody can dispute that. The point is that there are things you can do with uBO lite that you can't do with uBO (and vice versa!). It's not a straight downgrade, there are powerful new features.
Again, we really need to separate "MV3 - the theoretical idea" and "MV3 - the actual implementation which ships with Chrome". It's two confusingly different worlds.
Nobody should be swaying you to prefer DNR over webRequest (or vice versa) when other browsers show both can be available options for the extensions you use as makes sense for what they try to do/what type you'd like to install. Continuing to support MV2 power levels of functionality does not mean uBO Lite type extensions would need to stop working the way they do, it means uBO type extensions would continue to work the way they do. I.e. the biggest failure of MV3 is not in lacking anything new whatsoever, it's in forcing the removal of a lot of API options which were useful in the name of ulterior motives.
> You can definitely do anything that DNR can do with webRequest, nobody can dispute that. The point is that there are things you can do with uBO lite that you can't do with uBO (and vice versa!). It's not a straight downgrade, there are powerful new features.
It's like you sold your house for a mobile home but tell the neighbor it's not a straight downgrade because it's red. Great, but why are we praising that instead of painting the house red?
Funnily enough, this morning I ran across another feature I didn't realize was missing in MV3 https://github.com/uBlockOrigin/uBOL-home/discussions/369. Perhaps keeping the functionality to know what was actually blocked to the extension was too powerful.
> the biggest failure of MV3 is not in lacking anything new whatsoever, it's in forcing the removal of a lot of API options which were useful in the name of ulterior motives.
What was the ulterior motive? If it was to break ad blocking, it seems like they did a really terrible job, as MV3 ad blockers work great. That's not me saying that, here is a paper from researchers at Goethe University Frankfurt who tested it:
> Moreover, cross-browser experiments yield comparable outcomes, and visual inspection confirms that MV3 ad blockers work effectively without significant ad flickering or loss of functionality
> Funnily enough, this morning I ran across another feature I didn't realize was missing in MV3
I think you could accomplish this by redirecting instead of blocking, then increment a counter in a webRequest callback. There would obviously be a performance cost, as blocking is so cheap and callbacks are expensive...
Regardless, I think it's jarring hearing you call custom DNR rules "painting the house red", a legitimately powerful feature... and then point to a missing counter in the UI as evidence of lacking features!
> content can load without the blocker being ready to
That issue does not exist for uBO Lite. I specifically wrote in the FAQ under "What are the upsides of an MV3-based content blocker?":
> For Chromium-based browsers specifically, MV3-based content blockers which are entirely declarative will properly filter at browser launch, which is not the case for MV2-based content blockers
uBO Lite is entirely declarative, so it filters properly at browser launch, and I literally give an actual example of this in the following section, search for "filters properly at browser launch".
The companies that don't want you using the lite version are waiting for full version to completely go away before blocking the lite one. No sense driving you to that. So, check back in a couple months and see if it's all still good.
I've seen some ads slip through the cracks nowadays, like I think Wikia ads for some TV shows I go to now have ads on them. They gave up on blocking Meta.
I believe the main things are that block lists have to be updated through the Chrome Web Store and there is an upper limit for things that can be blocked.
The main reason uBlock on Firefox works better is because of CNAME de-cloaking. All the tracking shit that appears to load as first-party, but isn't, can be correctly detected and blocked on Firefox. On Chrome it cannot, and with Google, Facebook, et al. encouraging site owners to move to these fake first-party conversion tracking solutions, your exposure to profiling has increased dramatically. You may see fewer ads but it does not do the same job.
Isn’t the idea that over time chrome will limit what ubo lite blocks? It will phase out all of its own ad networks so they’re not blocked first, but it’s possible they also start allowing third party ads through for a price.
Interesting but how is an "autoresearch loop" different than creating a spec and X number of testcases and letting an agent run against these testcases and the spec?
After some consideration, I also applied this convention to every site I build - including content negotiation: Clients can either send an Accept header with their preference, or append an explicit extension (.md|.markdown for Markdown, .json for JSON API responses, or .html for the human HTML page). Together with the content negotiation part, it feels very much like HTTP was intended to work - especially the fact that API clients, AI agents, and humans all use the same URLs, but get the content in the shape they need.
I've done this off and on for various sites over the years too, and probably should be more consistent about it. A number of sites do or used to do some variation of this, and I wish it was more widespread. E.g. Reddit will serve up a json version of a sub-dreddit if you do /r/subreddit.json
(It includes the grandparent's head link suggestion, but it's not just "change .html to .md" because I'm old skool and as a wee nerd was told that URLs ending in .html or .php or whatever we're frowned on, so the above link's markdown is available by appending /index.md )
My point was that llms.txt not working is no different from them ignoring everything else that came before and probably everything that is yet to come.
If they want it, they will take it, polite directives in text files will have no effect.
They were originally on their own datacenters + huge amounts of burst and ancillary stuff in AWS, the internal push to move away from "the competitor's cloud" after the acquisition was huge and entirely stupid. I'm ex-GitHub and was one of the annoying people constantly saying GitHub should only move where it was provably the best option for GitHub - the third best major cloud provider is likely never it on merits alone.
If this story is true, it's good that they finally realised that GitHub's performance and availability mattered more than using Microsoft's products. It would mean someone finally came to their senses rather than forcing a wholesale push to Azure - but I bet they still want to have it both ways even if they concede some AWS now.
In the early 2000's they did the same dumb thing to WebTV: forced a move from Solaris to Windows, that completely wrecked the engineering team's velocity and motivation.
I can definitively say llms.txt is not used by any AI players. I run a blogging platform with around 80k blogs and /llms.txt is not requested by anything (other than humans checking to see if there's an llms.txt path).
All regular pages are aggressively scraped to the extent it's a problem I have to consistently manage, but not llms.txt.
If you want to see what that looks like, I one-shot a browser with Claude that does it[0]. Docs pages are early adopters to this[1][2], so that AI agents can better handle tasks.
reply