Google did NOT backtrack on ANYTHING. From the new thread:
> Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still narrowing down proposed changes to the webRequest API.
"We are still narrowing down proposed changes" means they still plan on removing the part of webRequest that everyone cares about, the feature that lets it block requests.
There was an initial thread about these changes: https://groups.google.com/a/chromium.org/forum/#!topic/chrom.... Lots of people made great comments about why the proposed change was a bad idea. What did Google do? Ignore the thread and post another about how they are "iterating" on Manifest V3. Google's strategy is clear: wait for the outrage to subside, keep making new threads to divert discussion if you have to, then go ahead and make the changes you were planning on anyway.
Keep in mind that their story about performance has been shown to be a complete lie. There is no performance hit from using webRequest like this. This is about removing sophisticated ad blockers in order to defend Google's revenue stream, plain and simple.
Did you read the article? That's what it's about. I'm actually really surprised you posted this, the whole article is about Cliqz doing a performance test and finding that the claims about ad blockers hurting performance were not true.
My own personal experiments show that even with huge rule lists, the latency incurred on the connection is barely above the noise and improves loading times on most websites by mulitple magnitudes more than it could increase latency.
Well quite frankly, I dont care what google does. I am doing if old school since forever, squid proxy doint mitm. And it works for all my OSes from android to linux laptop. It is not as easy to set up as in browser ads blockers, but is completly out of control of browser and ad blockers or OS vendor. Anyway there is firefox too, while for chrome, as everything from google, I can only say - I told you so (10 years back).
Btw, it is quite interesting, that over all those "we were right" years, people are still trying to confort themself about how great their favorite brand is, we have a saying that even donkey walks on ice only once.
Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years.
I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Rust adoption, Firefox got fast. This means my web products work a little better on Firefox, intentional or not. When enough people make that choice, a tipping point forms in the future. Paul Graham wrote about this in "The Return of the Mac" [^1].
Don't underestimate the power of your choice at the frontier, even if it takes a while to reverberate through time.
What’s frightening is that most people agreed with his views, but weren’t willing to commit to them because of practicality. I of course am one of them.
Decades later, I think we are still at a point where following his ideas come at a very steep price in performance and day to day usage.
For instance any dev that touches an iOs app in any way or form (even if it’s just to run in on test devices) is better off with a mac.
There’s ton of prevalent android apps that won’t work without the Play Store, and even rooting the phone is already seen as an hostile act from many vendors.
The list goes on and on, keeping hardware or software free is still an insane move that needs sizeable sacrifices. And it’s scary there’s no indication of the situation to change for the better.
Footnote in pg's article makes me wonder what the stats are today. I'd guess Windows down, Mac way up, Linux/FreeBSD about flat [maybe slightly up], but I have no idea.
[2] Y Combinator is (we hope) visited mostly by hackers. The proportions of OSes are: Windows 66.4%, Macintosh 18.8%, Linux 11.4%, and FreeBSD 1.5%. The Mac number is a big change from what it would have been five years ago.
Wow, that the majority is Windows is a bit unexpected to me. Really shows how powerful and omnipresent Windows actually still is - something that is often forgotten when living in certain tech bubbles.
Linux with 11% is quite high, I like that. What seems lower then expected are the Mac numbers to me.
The difficulty is that many of those examples are also doing useful things that the more open/free alternatives aren't.
We are developing an unfortunate dichotomy between commercially supported, closed ecosystems with lock-in and rapid update cycles that provide superior functionality and more community-driven, open ecosystems with standards and future-proofing but inferior functionality.
If the open versions aren't too far behind the closed ones in functionality and performance, that's just another form of competition and perhaps a healthy one. But if we start to get too much lock-in, which is inherently a one-way process favouring the closed systems in this situation, and in particular if important data or external systems become accessible only from the closed systems, then we have a more serious problem, as we're seeing ever more clearly with the worlds of mobile devices, IoT and "evergreen" software.
That's the choice we each have to make for ourselves. Be a serf in corporate walled garden for short term convenience, or help build and improve the open ecosystem so it can catch up.
> Be a serf in corporate walled garden for short term convenience...
There is a spectrum from the cathedral to the bazaar. And there are only so many hours in the day. You could become a serf to principles, spending time others have for social activities or relaxing instead on maintaining a purely libre work flow.
There's a fundamental difference between you owning your tools and somebody else loaning them to you. You can save some time in the short term. However once the company starts going in a direction that doesn't work for you, then you end up getting screwed. I've been burned enough times over the years that I'd much rather use open source tools whenever possible. The beauty of open source tools is that they're not driven by need for profit. As long as there's a community of users who want to use a tool then it's going to keep being maintained and working the way the users want. It doesn't need to be profitable or grow it's market share.
So I'd much rather be a serf to principles and have control over my life than be a serf to a bunch of companies with their own goals and agendas. That's just me though.
However once the company starts going in a direction that doesn't work for you, then you end up getting screwed.
That is true, but if the more free/open alternatives were never at the same starting point in the first place, you were probably screwed that way too. Neither option let you start in a good place and then move in a good direction, and this is the unfortunate reality I was commenting on above.
I think open source does let you move in a good direction though. I switched from a Mac to Manjaro Linux for my main desktop, and I haven't missed anything so far. Latest Gnome and KDE are both really nice desktops, there are apps for everything I need, and the OS is rock solid.
I've used Linux on the desktop previously and it left me wanting, so the fact that I haven't gone back tells me that things are indeed improving.
Meanwhile, OS X hasn't added a single feature I use since 10.6. All I've experienced over the years is that it kept getting more bloated, slower, and flakier.
That's the choice we each have to make for ourselves.
Yes it is, but the reality is that if almost everyone is making the other choice, we stand to lose a huge amount by not following the crowd. That's not a price that most people are willing to pay, which limits the interest in and contributions to the open alternatives, and thus the vicious circle is closed.
It's not about the total users you have or marketshare. The only thing that's important for open source is that there are enough users to keep it going. And that's certainly been the case for many years now. The fact that most people use something else doesn't affect me one bit vast majority of the time.
Well, it got faster because of Servo, which is written in Rust, so not completely unrelated, but yes, it did not get fast because of Rust the language.
I think in this case it’s probably because the person in question is simply mistaken. The other possibility is that they are some kind of Rust evangelist and they are actively trying to deceive people. I doubt it. Could we please approach each other with the benefit of the doubt? Could we please gently, constructively correct errors? I see no need to be so aggressive, especially in our current social/political climate.
What current social/political climate? Moreover, the problem is that he claimed without research. And this is what bothers me. How can people be certain of something they have never seen confirmed anywhere.
I tried switching to Firefox about two years ago and went straight back to Chrome because it was so slow. It would lag when I opened a new tab and started typing to get to another site. Many times, the first few characters off a hostname or search would get dropped.
Tried again about six months ago, and I haven't looked back. Firefox is great again. Not sure if the Rust adoption happened between those two points in time.
I still have to use Chrome for Hangouts for work. And still trying to figure out a way around this.
This is a common misconception. In key benchmarks, it is the same speed (a few still lag, but not due to inherent weaknesses in the language). Earlier versions of rust were slower because the compiler didn't have the insane optimizations that many C++ compilers have.
In fact, it may be easier for developers to write code that runs faster with rust than C++, thanks to much error and exception handling code that you simply do not need in Rust.
Most importantly, however, is finding Rust developers who are experienced enough to write high-performance Rust. I would imagine that it's a lot easier to find C++ devs.
It may be, but there's also the concurrency aspect which is hard to get right in C++. That's where the performance gains come from, partially, because 'fearless concurrency' is one of the Rust's tenets.
They've done nothing of the sort. The ZDNet article quotes:
> "Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3," said Chrome engineer Devlin Cronin [emphasis his].
But the full quote shows what he's talking about:
> Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still narrowing down proposed changes to the webRequest API.
The only commitment is to not modify the read-only "observational capabilities".
Sounds like Google will still move towards what they were planning but will likely just take a bit more time and more versions to get there (as the outrage subsides).
From my perspective, the biggest improvement in their proposal would have been the increased privacy and security users would receive with adblockers that use the proposed scheme.
Under the current scheme, any Chrome adblocker can see all of the pages that users browse; a potentially huge privacy hole.
At least with the proposed scheme, adblocker extensions wouldn't have had access to a user's browsing history. This is the same approach that Safari uses with its content blocker API.
Yes, the Safari approach has more limitations, but it is also significantly better from a privacy perspective.
> Under the current scheme, any Chrome adblocker can see all of the pages that users browse; a potentially huge privacy hole.
I hate that argument if it's used to cripple the users ability to have full control of their own devices. It is NOT a privacy hole when you install software that has access to your data. If you don't want that, don't install that software. If you don't trust that software, don't install it.
Google isn't removing any ability to observe, log, and forward information about requests, in any way.
So the privacy angle is pure bullshit.
They are removing, among other things, the ability to dynamically cancel requests, and replacing it with a declarative API. That limits how well an adblocker can function.
When users try to install a Chrome extension, the browser is telling them what permissions it needs, e.g. the capability to read browsing traffic. So you could just decline the installation and install a different ad blocker that works without that permission.
"At least with the proposed scheme, adblocker extensions wouldn't have had access to a user's browsing history."
No, that's not true. They aren't removing onBeforeRequest() and friends. They are only removing the "cancel" function in it.
Extensions can still log and forward every request.
The only tiny kernel of truth here is that an extension that only asks for the declarative API permissions couldn't do that.
I doubt there will be any popular blocker that only asks for that declarative API. They still need access to onBeforeRequest() for any sort of heuristics to allow the user to add/change rules based on page behavior.
Also, separately, extensions can inject JS into the DOM. So they can do anything that Google Analytics can do anyway. Like track visited pages.
As per the quotes in other comments on this article, it sounds like the 'observational' functionality of the API is staying, so this doesn't seem like a win from a privacy perspective at all.
At some point, new ads the system can't block will surface. The adblocker will become less and less useful, and Google will have no incentive to improve it.
There is already a big difference between even existing adblockers. E.G: some show youtube ads.
And I'm much more worry about the privacy concern from many random ads poping unexpectedly, than from one extension that the entire community get to vet.
A better example of how this could be done is iOS keyboards. They’re run in a sandbox (by default), and they have no internet access. An ad blocker could be sandboxed like this. Sure, such a sandbox can be bypassed by intentionally leaking bits through keyboard input or, in the case of an ad blocker, exactly which requests are blocked, but that would be very obvious nefarious behavior.
I like that idea, but it would be hard to pull off. The extension API, for example, allows for messaging between background scripts and content scripts. So you could make a proxy of sorts. And messaging is not the only hole you can poke. They would essentially have to redesign the whole extension API. To the point where no interesting extensions would be possible.
Surely there could be a content blocker script that simply can’t send messages anywhere. It gets access to web requests and to IndexedDB or something similar. It can receive messages from other extension scripts for updates, perhaps.
The Safari approach is next to useless, because it can be easily circumvented. That many publishers don't do it, that's only because they don't have the know-how or because they don't want to piss off what's still a minority.
Note that the browser is the "user agent", acting on behalf of the user and extensions are for extending the capabilities of the user agent. The browser should be yours and should do what you tell it to do.
Users only need one or two extensions that they need to trust. Can't you trust uBlock Origin? If no, given its open source nature and the people that work on them, then why can you trust Chrome and Google more?
The privacy angle is a complete red herring.
Yes, Chrome's Store is filled with spyware, but that's Google's fault for having a broken review process. Firefox (addons.mozilla.org) does not have the same problem, in spite of the fact that Firefox lacked permissions until the Quantum release.
> Under the current scheme, any Chrome adblocker can see all of the pages that users browse; a potentially huge privacy hole.
Isn't there solution to have the blocker send a limited list of declarative block-rules of a particular style?
Why not just let the adblockers pass in an uncapped quantity of javascript that will run in some kind blocking context, but be sandboxed from any external outgoing communication? That would give the flexibility of the current adblockers, but still plug the privacy hole.
This is a win-win situation for Google. I doubt they haven't done the maths.
If they lose a percentage of the userbase, but get increased revenue, it's only logical to do that.
If their userbase decreases, their monopoly status also decreases, making regulation harder.
The percentage of users who install firefox is low because of the inertia of the default. Having Google as the default search engine in firefox certainly didn't help.
Imagine downloading firefox to replace IE or Edge on a fresh Windows install and then immediately witness Chrome ads in your search results.
Mozilla should had disrupted the third party tracking/ads business, when it had the chance, by providing a default ad blocker and severing ties with no-privacy-respecting search engines (before Google disrupted the browsers market that is).
Google's Android browser is doing well by not supporting extensions, why would they miss the chance of additional revenue by not crippling their desktop browser the same way?
Not seeing any comments here about the most interesting part of the OP: how Ghostery ran tests disproving Google's claim about the length of ad blocking lists causing noticeable performance degradation. Yet in the mailing list announcement from Google that instigated this article they doubled down on that claim:
Increased Ruleset Size: We will raise the rule limit from the draft 30K value. However, an upper limit is still necessary to ensure performance for users. Block lists have tended to be “push-only”, where new rules are added but obsolete rules are rarely, if ever, removed (external research has shown that 90% of EasyList blocking rules provided no benefit in common blocking scenarios). Having this list continue to grow unbounded is problematic.
Yet, if there's a limit it will also be problematic. The lists only grow in size because of the cat-and-mouse game caused by ad blockers existing in the first place. If there's a size limit, that immediately gives a win to the ad servers because they will find a way to subvert the known limit.
As people said in the thread about the actual study, this isn't a real backtrack, they're still locking down the rules, just being a bit more accommodating to the current gen of adblock, but the second ads adapt around current tech, adblockers will be stuck in the mud.
No, they become the gatekeeper for all adblock features. "low-level" is a meaningless qualifier here.
> And if new api features are being requested by adblockers, who is really innovating?
Right now, adblock developers are speaking out, in droves, requesting that they don't remove the API features Chrome already has, and Google is saying "nah."
They are wiping out the current diversity of ad-blocking techniques and saying "This is the way you can build an ad-blocker now." There is also the obvious conflict of interest that many of the ads in question are served by Google in the first place.
Chrome may or may not be the best browser. But Google properties tying into Chrome as a platform (think sync, extensions, auth, captchas) and making it really difficult to switch away creates a situation where it's not all about choosing the best browser any more. This harkens back to the same anti-competitive monopolistic behavior that Microsoft got sued for in the late 90's.
The best browser isn't the fastest. It's the one you can trust to serve you and not some corporation or government that wants to control what you see and where you go.
The problem with forks is having to chase upstream. The dominant browser can keep making changes with reckless abandon. And the fork has to keep up with those, even if it breaks their own features, lest they become incompatible with the "standard" version.
chasing upstream is a lot easier than chasing web standards and chromes performance, especially if you are only interested in providing more powerful extension api and better ui
I never understand the intent behind introducing this move - is it greed for more ad money through lockdown ? The company is literally a monopoly and still it wants more. This seems like the company is bowing down for shareholder supremacy.
In my opinion its not really a conspiracy. People at Google are so far up their own ass that they don't understand the importance of content blockers.
Personally I just can't deal with websites without ublock modifying them.
Exactly, the experience on the web is much better with ad blockers!
EDIT : I think my first comment triggered a bit of discussion. I also don't think there is any conspiracy (conspiracy is a big word :) ) - because I didn't intend to portray it that way. What I did want to convey, from the vantage point of a user, is that the priorities didn't seem to align.
Depends on what you consider a "conspiracy". The word "conspiracy" sounds unnecessarily controversial and mysterious. It seems plausible and probable to me that there are economic motivating factors at play.
The initial proposal was for a static list of blocked uris, and no api to add an item to the list.
That really speaks to a conspiracy to me. What plausible reason would there be for that? You would have had to push a new version of an extension to change the list. There's no way that omission was an "oopsie".
I don't think they are far up their ass. They don't give two shits on a popsicle what tech users think. They have an absolute monopoly on almost everything on the internet. Apps, ads, search, phones, browser. Where we gonna go if they kick us out?
> I never understand the intent behind introducing this move
I think the reasons provided are valid (namely, faster blocking with less data flowing through extensions), whether or not you think they are good enough to outweigh their disadvantages.
I think you should read this part of the article too :
"Their study --which analyzed the network performance of ad blockers such as uBlock Origin, Adblock Plus, Brave, DuckDuckGo and Cliqz'z Ghostery-- found sub-millisecond median decision times per request, showing quite the opposite of what the Chrome team claimed."
What are they really optimizing for ? The sub-millisecond times per request is barely noticeable, and on any given day its much preferable to ads tracking you everywhere on the internet!
I read the article the quote was pulled from, as well as participated in the discussion and responded to the author when it was posted here. Just FYI, Safari (which already has this feature in the form of content blockers) is able to block ads just fine, and anecdotally the performance is slightly, but noticeably better.
The question still remains: what are they optimizing for if we already have sub-millisecond response times?
The only evidence you offer is anecdotal. I'm having a hard time imagining perceptible differences in sub-millisecond response times so either you or the study are in error.
And just to reiterate other comments: yes, Safari is probably able to block ads just fine now, because they modeled the engine according to capabilities needed right now. However, it comes at a huge cost to innovation and creates yet another barrier of entry guarded by a large corporation.
Taking all of that in account, it seems unnecessary. The looming threat of ulterior motives from Google remains ever-present.
To be honest, I'm much more in favor of this API because of its privacy features than performance. I think it's a little bit faster, but it has a much bigger benefit on the trust side because extensions no longer run arbitrary JavaScript in every page I visit.
It's very improbable the few popular ad blocking extensions could slide in something sinister and avoid public scrutiny for a long time. You have much more reason to be worried about your privacy from Chrome than from uBlock Origin, since Chrome and Google provably violate it.
JavaScript code will take a millisecond to decide whether to block a request or not and some hard-coded browser function will do it slightly faster, but not by much, because most of the work will be done by the same regular expression, so we are talking about fractions of a millisecond here and you claim to notice that?
Safari pre-compiles the blocking list into some internal representation that is faster than a raw regular expression, and the matching operation is performed many times per page. So I do think it's possible to notice a small performance benefit?
To filter URLs, you have to parse them, check if the domain is blocked using a hash table and then search for thousands of substrings in the path and query parts of the URL. If you use a regex for that, most of the filtering will already run in native code. I guarantee you that this gives you a tough to beat baseline with almost no room for improvements.
Looking at the WebKit implementation, the authors are shipping their own regex engine for whatever reason. I doubt that it beats the battle-tested re2 engine by large margins, if at all.
I don’t think the content blocker API allows for the full set of features you’d find in standard regex library. This might mean that WebKit can roll their own regex library that’s better optimized for this subset?
Yeah, the user experience with current ad blockers is that browsing is way faster then without an adblocker. So anything Google states here is dodgy at best.
That justifies adding the new API, it does not explain removing the old capabilities. They could nudge extension developers to try the new API by adding some "extension X may slow down page loads" warnings somewhere if they don't use it.
It's also likely that the net gain in performance by blocking resources with heuristics (that wouldn't be blocked by a simple pattern) outweighs any loss. At least for many websites.
The only argument that made sense to me was the one that the current APIs makes it quite difficult to reason about what the extension actually does once installed and running.
By dynamically installing rules downloaded from the web a nefarious ad blocker could, for example, not just block ads but also hide certain political content from search results.
By requiring the list of rules to be hard-coded in the extension, it's easier to see what exactly the extension will do once installed.
For me though, this benefit does not outweigh the cost.
That's an interesting thought, but extensions can still hide, inject, or replace content. They just can't avoid downloading the original by any criteria other than uri patterns.
Sure, but the idea, as I understood it, was that by locking down the APIs such that they can't change behavior post-install, any such patters would be visible on inspection.
For example, extensions are already rejected if they contain minified scripts as that also obfuscates what happens. This could be seen as going one step further.
Ah, yes. The separate set of manifest v3 proposals that disallow external and/or obfuscated code. Probably a good idea at a high level, but it does break good stuff like TamperMonkey (10 million users...ouch).
Coincidentally Chrome 72 upgrade seems to break adblockers so that they can't block google analytics, and maybe other ads/tracking as well, if web page uses a service worker: https://news.ycombinator.com/item?id=19185637
Someone pointed out that every Chrome user got that way because a techie got them off Internet Explorer... and those same people can just as easily get them onto Firefox.
That was the original reason, yes. Now Chrome is installed by default on tons of new laptops etc because Google makes so much money by tracking users via Chrome that they can pay serious $$ to manufacturers to tweak their base build.
>> Someone pointed out that every Chrome user got that way because a techie got them off Internet Explorer... and those same people can just as easily get them onto Firefox.
> That was the original reason, yes. Now Chrome is installed by default on tons of new laptops etc
So Chrome is the new IE now, and the GP comment stands.
Some of them may also have got that way because of the billions Google spent advertising Chrome. I doubt Mozilla could afford to put Firefox ads all over the web to anything like the same extent.
You seem to have forgotten the extremely agressive marketing from Google. At some point, practically all major free software was bundled with Chrome, which installed by default. It was almost similar to malware in its persistence, and adopted many dark patterns just for the opportunity to get on your PC.
Dear Google, you have a chance to do so much good! Don't fritter that opportunity away for easy dollars! We know ads are your cash cow currently, but you seriously have enough cash and talent to generate cash flows from less annoying (and perhaps, useful) things. Have some faith in your people. And above all, please don't be evil, and don't fib.
Dear DuckDuckGo, please can you focus a little less on search, and more on a producing a high quality browser? Seriously, I feel if you want to rid the world of Google's stranglehold, you don't need to make a better search engine, but a better browser. Google has bloated Chrome enough that any alternative that is lightweight, cross platform, with a solid password manager and dev tools would make me jump ship in a flash. Be sure to support PWAs too. And shorten your name - duckduckgo as a name is a bit weird - your new domain, duck.com might be worth doubling down on. Thanks!
Maybe now people will start to use Tor Browser for daily browsing. If you are inside EEA you don't even have to actually connect to Tor network just use Tor browser.
The sub-title immediately below the title is: "Google changes stance on upcoming Chrome Manifest V3 changes as benchmark shows they lied about performance hit."
Personal attacks, which this crosses into, are not acceptable on HN. If you feel that another commenter is abusing HN, please let us know at hn@ycombinator.com so we can look into it. Casting aspersions on another user simply for disagreeing is not ok, so please don't do this again.
p.s. What you said about "every single one" of devrand's comments is far from accurate. It's not ok to haul in someone's comment history as ammunition in an argument, and even worse when what you say is not true.
> Following the publication of this study, Google engineers made it official on a Google Groups posting hours later, announcing a relaxation of the Manifest V3 changes that would have impacted ad blockers.
There is no backtracking or lying here. The thread states:
> there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request).
This was the plan in the earlier thread as well. The API wasn't going away, they were just removing blocking and modifying.
The article also goes hard on how they clarified that "they never intended to prevent or break content blocking". Again, they never said they wanted to limit this, they were just "moving fast and breaking things" by requiring the content blocker extensions to move to a new API. The original thread mentioned uBO because it was going to be the main source of discussion due to it having 50k+ rules already.
What are you talking about when you say "they never said they wanted to limit this"?
This whole scandal was because the DeclarativeNetRequest API was limiting request access. That's the MAIN REASON the uBlock Origin author complained about.
>>Google changes stance on upcoming Chrome Manifest V3 changes as benchmark shows they lied about performance hit.....Hours after the Ghostery team published its study and benchmark results, the Chrome team backtracked on their planned modifications.
Adios Google that once was. Ad blocking does cause performance issues, but revenue ones.
Ahhh, I'm lazy and wanted my final reason to switch to FF. Oh well, I'll let google track me through browser for now, if they leave my uOrigin+NoScript alone. The second those won't work I'll make the switch.
> Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still narrowing down proposed changes to the webRequest API.
"We are still narrowing down proposed changes" means they still plan on removing the part of webRequest that everyone cares about, the feature that lets it block requests.
There was an initial thread about these changes: https://groups.google.com/a/chromium.org/forum/#!topic/chrom.... Lots of people made great comments about why the proposed change was a bad idea. What did Google do? Ignore the thread and post another about how they are "iterating" on Manifest V3. Google's strategy is clear: wait for the outrage to subside, keep making new threads to divert discussion if you have to, then go ahead and make the changes you were planning on anyway.
Keep in mind that their story about performance has been shown to be a complete lie. There is no performance hit from using webRequest like this. This is about removing sophisticated ad blockers in order to defend Google's revenue stream, plain and simple.