> 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.
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?
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.
(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.)
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
> 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.)
> 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
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.
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.
I fear this will have significant consequences on the youtube vs ublock war. A key component of how ublock prevailed is by devising mechanisms to push instant updates of the filter lists. Does the chrome web store allow timely updates, or will they be significantly delayed? Or do the filter updates not go through the store?
The wiki is publically editable, I think your suggestion is great but you seem to have a good idea of how it could be done, would you be willing to take a stab?
Manifest v3 was introduced in 2018. By the time v2 is deprecated (if it ever happens), the transition will have spanned three US presidential administrations.
I don't think it matters for Google. Google is an ad company. Every customer with an ad-blocker is not a customer, it's just a cost. The same goes for every single site on the Internet that has ads. None of them will care if someone who doesn't see ads can't access the website any longer.
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.
the problem in my opinion is the perceived value of an individual video.
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.
I’m just not going to update and limit the sites I visit. If I need to go to a more risky site, use a browser I have auto-update on to keep latest patches and vurlns at bay(ish)
This has taken so long I originally switched to Firefox a little less than ~4 years ago, switched back a couple years later and continued using v2, and have now switched to other Chromium based browsers that weren't even announced at the start of this journey.
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.
Based on current trends, it seems Brave will be the only browser that maintains Manifest v2 support in Chrome. They have a specific panel in settings that allows installation of specific extensions, including uBlock Origin.
Brave has been a bit gray about it. E.g. sure they have that panel and say they'll do things to support it but then when pressed on how they'll say they'll only keep doing that as long as the code paths remain in Chromium. I.e. they are more than willing to keep it enabled but not necessarily willing to commit to maintaining it if/when it is removed from upstream Chromium.
For the moment, the best possible solution seems to me simply disabling auto-updates. On long-term, if supermium can port over the critical fixes from chromium, ubo v2 may still survive with chrome-ish packaging.
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.
Came here to see what exactly that meant for UBO and didn't see anything so posting the below:
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"
> 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.