About Google Chrome's "This extension may soon no longer be supported"
github.com
github.com
> Starting on June 3 on the Chrome Beta, Dev and Canary channels, if users still have Manifest V2 extensions installed, some will start to see a warning banner when visiting their extension management page - chrome://extensions - informing them that some (Manifest V2) extensions they have installed will soon no longer be supported. At the same time, extensions with the Featured badge that are still using Manifest V2 will lose their badge.
> This will be followed gradually in the coming months by the disabling of those extensions. Users will be directed to the Chrome Web Store, where they will be recommended Manifest V3 alternatives for their disabled extension. For a short time after the extensions are disabled, users will still be able to turn their Manifest V2 extensions back on, but over time, this toggle will go away as well.
Time to say goodbye to Chrome.
Thank you, Raymond Hill.
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?
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...
I’m not clear on what “bad things” they wheee imagining though?
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.
> 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.)
Googles brand is becoming more and more toxic, from my perspective.
Thankfully you can turn it off.
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.)
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
Inform people instead of what could be read as "I'm just not doing it".
Firefox user here since before it was Firefox so I see this as a chance to educate.
Also, is there an arrival date for V3 now?
(I'm probably in a minority)
It'll be interesting which Chromium downstreams end up maintaining manifest v2 vs which pitch built in blocking a la "but we have adblocking at home" style and how that actually pans out in where the power users go.
> Now: Time to Migrate > June 2024: MV2 Consumer Deprecation
> June 2025: MV2 Enterprise Deprecation
manifest v3 has been pushing out since early june this year, for stable releases i think.
https://news.ycombinator.com/item?id=38301801
https://www.eff.org/deeplinks/2021/12/chrome-users-beware-ma...
I don't really "use Youtube." The algorithm has a ridiculous recency bias so it's full of the newest drama, which I dislike. And even then for a lot of things I'd rather have text than video. But I know a lot of people spend hours every day on Youtube and they will not purchase a subscription to get rid of ads, and they will instead use an ad-blocker. They won't donate to Youtubers but they will use extensions to skip parts of the video that talk about sponsorship.
It makes me think... if people won't pay a subscription to watch hours and hours of video online, they won't give money for anything less either. I've seen some say that they use ad-blockers because some ads may contain malware, or because of some privacy concerns, trying to keep their high moral ground while they access content without paying. The alternative of just... not accessing Youtube or ad-infested websites if you don't like their business model doesn't seem to cross their minds. If the entire Internet was really so full of malware ads trying to steal my private information, I would have uninstalled my web browser ages ago.
To make matters worse, the few websites that do not use ads have paywalls. Guess what happens then? If you post paywalled content, people complain it's behind a paywall. Paywalled contained is looked down upon, compared to freely accessible content, which contains ads, but the ads are ALSO looked down upon. Someone will copy the paywalled text and post it on social media for others to access for free, without ads.
It makes me think that the problem was never the ads.
if youtube videos were looked at, as must have, viewer support might tick upward a bit. the value is probably connected to the creator of the video rather than youtube itself. i personally look forward to hearing from the creator,rather than the conduit, if there was a way to just mail a 5er to the actual video creator, no problems, i would do that.
This new in-browser-browser can then have a good support for stuff like uBlock Origine or whatever else one pleases.
This way you still use chrome while making chrome irrelevant.
For larger context, the ecosystem is fragmenting, and I have ~10 browser extensions that are critical to me. I don't think I will prioritize chrome's software cadence over my own preferences, thank you.
Raymond Hill, the creator and maintainer of uBO, has made it clear that he will not be trying to adapt uBO to Google's Manifest v3 – the extension architecture that is replacing v2.
"You will have to find an alternative to uBO before Google Chrome disables it for good"