> 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.
Citation needed. My personal experiments show that blocking webrequest has more latency than the network connection!
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.
I use Pi-Hole, but I also use uBlock Origin since Pi-Hole cannot block ads that require more advanced heuristics to block, like YT ads for example.
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.
> "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".
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.
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?
How do you expect Mozilla to undercut a major funder?
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.
Saying we need multiple browsers, then using chrome or its clone actually makes the situation worse.
Also chrome is no longer snappy as it was initially.
https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
> 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.
Its so frustrating.
https://github.com/domenic/proposal-function-prototype-tostr...
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!
Then again, by that point it might be better to just switch to Firefox.
Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here.
> "... please use the original title, unless it is misleading or linkbait; don't editorialize."
Adios Google that once was. Ad blocking does cause performance issues, but revenue ones.
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.
Read faq.
[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.
Linux with 11% is quite high, I like that. What seems lower then expected are the Mac numbers to me.
Thanks for sharing.
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.
Those are unrelated.
The third time, they used Rust. And it worked.
Mozilla research said rush enabled them doing safe multuthreading.
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.
https://blog.mozilla.org/blog/2017/11/14/introducing-firefox...
- People preferring the compiler to yell at them to fix their Type mistakes before they hit the "run tests" button.
- Getting a better IR for better error messages.
Amongst others...
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.
That's a bold claim to make without any justification!
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.
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.
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.
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.
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.
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.
Edit: Apparently Google is actually not plugging any privacy holes, since it will still allow monitoring: https://news.ycombinator.com/item?id=19184169
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.
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".
They did back off on that.
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.
"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!
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.
The way I would put it is that Google becomes the gatekeeper for some low-level adblocker features.
> 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.
The good ones will still want onBeforeRequest() for heuristics and dom access for click-to-block.
The whole privacy excuse from Google is intentional hand waving. Decent ad blockers will still need permissions for scary sounding things.
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.
Again, not endorsing this move.
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.
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.
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.
Very true! Especially if the network impact is of the order of sub-milliseconds.
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.
The reason for not allowing intercept the connection was security: the current API allow the extension do many kinds of mitm
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'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.
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.