>As Vivaldi is built on the Chromium code, how we tackle the API change depends on how Google implements the restriction. The assurance is, whatever restrictions Google adds, in the end, we’ll look into removing them.
Is this not a serious wake up call for all these companies relying on Chromium? You are staking so much of your business on a giant conglomerate that does not care about you or your users, whose only aim to sweep up as much data from the web as possible to feed their ad machine.
I'm not sure a lot of these browsers have the resources to fork Chromium and stay "profitable" or whatever their goal is. Microsoft probably could but they gave up on Edge when it was pretty feature complete so I'm guessing that they would really prefer not to maintain a browser by themselves. I'd bet that most of the other Chromium-based browsers would not be capable of financially maintaining a serious fork where some fundamental internal APIs have been changed.
Microsoft had a chance of winning back Browser war by announcing Blink fork with V2 and 100% backporting of all Google changes. But "Microsoft reported more than $10 billion in advertising revenue last year", so they were reluctant to get this easy win.
Yes, I was pretty disappointed when Microsoft announced they would transition to v3. They already do so much customization to completely de-Google Chromium and replace it with Microsoft equivalent functionality (and adding new features on top of that) - it would have been almost a no-op for them to maintain v2 compatibility.
I think Microsoft is increasingly getting into the ad business themselves, and so may have the same incentive as Google in terms of neutering adblockers.
I don't think it's a preference thing. I don't think Vivaldi, or Brave, or any other company whose main product is a browser, can have the income to pay 1000+ engineers to work on the codebase to keep up with the pace of Google.
Maybe it should at the very least be a wake up call to companies which can't afford the engineer-hours it takes to maintain a Chromium fork.
There's enough of them and I am sure non-affiliated as well, they could likely scrape together enough engineering 'power' to maintain their own sane fork of Chromium.
They don't need to keep pace feature-wise. I don't need a featureful browser, I want a browser that performs well.
Last I looked into it; the problem wasnt with features. The Chrome code base is very dynamic and if you fall behind then it becomes very hard to pull upstream patches due to the pace at which things get refactored.
Mozilla (and Opera for that matter before) showed that one needed much smaller team to maintain a full-featured web engine. Plus a lot of Chromium complexity comes from the desire to make such big team manageable. So they split tightly coupled code into separated components worked on by different groups resulting in a lot of glue interfaces and wrapper classes.
Out of curiosity, does Google really have that many engineers working on Chromium? According to Wikipedia, Mozilla has ~750 employees and only a subset of those are working on Firefox.
The repository gets 500 commits per day. Assume the average engineer manages about 1 commit per day. Thats about 500 engineers working on it... [very rough, but ballpark correct].
And remember some people might be working on experiments/research/ideas that never make it into the repo.
And there are lots of libraries in other repos that kinda only exist for Chromium that Google also works on - eg. the Skia graphics library.
But... on top of those engineers will be UX designers, managers, HR, finance, chefs, and all the other people who make an organisation work.
> Absent security issues, what's the value of the last N releases of Chrome? How far do you have to go to get something of value that changed?
IMO something of value changes with every release. For example, in the most recent release (105) Chromium gained support for container queries and the :has() pseudo-class. Container queries allow web devs to change how styling is applied the contents of an element based on the size of the element itself. That's a major new tool for web developers & designers. 105 also supports the HTML Sanitizer API, which relieves the need to use libraries like DomPurify to protect against XSS attacks.
If you're interested in digging into what changes in each release, Chrome has a blog post series called New in Chrome[1] that summarizes changes. And to dive even further into changes, the Chrome Status[2] site allows you to filter platform feature changes by release milestone.
IMO this is a great chance for Microsoft to take charge and try to get back in the browser game.
They should fork Chromium and sign up all the others (Brave, Vivaldi, Opera) to help maintain the code base. Of course MS can afford to pitch in the maximum amount of resources, both human and financial.
This way we will have a serious contender to Chrome in the industry and they can differentiate themselves meaningfully from Google's hegemony in the space.
But they won't do it, it's hard to ignore those sweet potential ad monies.
The first problem with your (and a lot of peoples') proposal is the notion that a Chrome ripoff (aka a fork) is a valid competitor.
If you're going to sell me a Chrome ripoff, I'll just use the real deal. It's the same reason why Firefox died: They tried/try to ripoff Chrome, and as a result everyone just moved/moves over to the real deal.
On the other hand, I use Vivaldi fairly successfully when some site demands I use Chrome instead of Firefox. Most people won't of course, but it is a valid option.
Firefox is (and has been) no longer a consideration in web development because of its tiny and thus inconsequential market share.
Lest we forget, Firefox was once the market leader that usurped the position from IE6.
>they tried to rip off Chrome
The constant dumbing down and changing of the UI, removal of XUL in favor of WebAssembly (dropping Firefox extensions in favor of becoming compatible with Chrome extensions), moving to the Chrome Version Number system (we're on Firefox what again? 100? 150? 200?) to not look ancient comparatively, etc.
I'm sincerely of the opinion Mozilla should just drop Gecko and move Firefox over to being another Chrome fork. It would be far more in line with Mozilla's goals of shipping a Chrome ripoff in vain attempts to steal Chrome users.
> Firefox is (and has been) no longer a consideration in web development because of its tiny and thus inconsequential market share.
Is 7.4% of desktop users [0] inconsequential? Maybe to your business, but I think most would be sad to lose 7% of desktop users. I'll also note if this indicates "death" Safari is dead too.
I know XUL pissed off a lot of people, but I really don't think copying Chrome was the main motivation. XUL had a LOT of cruft and issues they wanted to escape and going to web extensions for some level of interoperability made sense, and looking at data from around that time [1] it doesn't appear to have cost them much of their user-base. It's also a perfect example of Firefox not copying Chrome, with Firefox supporting a ton of APIs Chrome doesn't or has removed [2].
As for the UI "copying" Chrome, I'm not sure how to respond to that. I just spun up vanilla profiles of Firefox and Chrome, and sure they both have tabs at the top, but they are pretty visually distinct. Yes Firefox has reduced the size of it's UI over the years, but if that's copying Chrome... I guess a lot of apps are.
Firefox may be in decline, and that makes me sad, but I think that has a lot more to do with shitty developers using non-standard Chrome APIs and then telling users to use Chrome when it breaks, while GMail and other Google properties cripple Firefox performance, rather than Firefox blindly copying Chrome.
Personally I hope this trend reverses. Firefox is the only thing stopping Chrome from becoming the next IE 6.
>Is 7.4% of desktop users [0] inconsequential? Maybe to your business, but I think most would be sad to lose 7% of desktop users. I'll also note if this indicates "death" Safari is dead too.
Nobody with a sane mind is going to bother spending time and resources on just 7.4% of the userbase, that's just a simple and brutal fact of reality.
I do think Safari is "dead" as a browser, it's not Chrome after all. But it's not dead dead yet, and the only reason for that is because it's the only browser on iOS which itself holds a significant minority share of the mobile space. Webdevs will support Safari not because Safari is worth paying attention to, but because iOS and its ~45%(?) market share is worth paying attention to.
>Personally I hope this trend reverses. Firefox is the only thing stopping Chrome from becoming the next IE 6.
I argue Chrome is already the second coming of IE6, and we've yet to see the second coming of Firefox. And whatever the second of coming of Firefox is, it's almost certainly not going to be anything to do with Mozilla.
If that happens I suspect they would lose a large portion of their userbase to Firefox. The main selling point for a lot of people is that these browsers are basically Chrome without the Google stuff. If they change to Quantum, why would people not just use Firefox? Unlike Chrome, Firefox is already fairly privacy focused, there's not as much of an incentive for people to use alternative Firefox-based browsers.
I currently use Brave, but if they switched to using Quantum I personally would just switch to Firefox proper.
> In general, the idea is that Edge developers check in their code to the internal Main branch. Code from Microsoft employees is joined by code pulled by the “pump” from the upstream Chromium project, with various sheriffs working around the clock to fix any merge conflicts between the upstream code pumped in and the code Microsoft engineers have added.
Microsoft have their own branch, where they add Edge-specific changes, and they regularly pull changes from the Chromium source (probably not all changes) and merge them to their branch. If you don’t consider this a fork, then please explain why.
>Eric S. Raymond, in his essay Homesteading the Noosphere,[12] stated that "The most important characteristic of a fork is that it spawns competing projects that cannot later exchange code, splitting the potential developer community"
At this point I just want to add that I'm not a developer and I don't actually know much, I just read stuff online. But yeah, Edge isn't a fork
> Distributed revision control (DVCS) tools have popularised a less emotive use of the term "fork", blurring the distinction with "branch".[14] With a DVCS such as Mercurial or Git, the normal way to contribute to a project, is to first create a personal branch of the repository, independent of the main repository, and later seek to have your changes integrated with it. Sites such as GitHub, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced, and GitHub uses "fork" as its term for this method of contribution to a project.
On GitHub, if you fork somebody else’s repo, your version is called a fork. You don’t have to diverge. You don’t have to merge. You don’t have to do anything, but it’s still called a fork. Do you agree that this is how GitHub uses the term fork?
Yes, that's how GitHub calls it, but by calling everything a fork the term loses its meaning. By this definition every Chromium browser is a fork, which is just ridiculous. Edge's developers don't think of Edge as a fork
Google announced that in order to achieve security we must get rid of all "remote code" execution avenues.
Really small print: "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google.
> "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google.
Replace Google with Mozilla, and you still have an accurate statement:
I don't even think you can say adblockers are a "power user" feature. The web is so bloated and bad that it's virtually unusable without it.
I hope this gets found as the anti-competitive move that it is. They're taking advantage of their near-monopoly that they have in the browser space to force people to view more of their own ads. It's disgusting.
Adblocking is the tip of the iceburg. Proxying, dev-tools that manipulate CORS, rule-based cosmetic filters etc... will also be impacted.
The other huge change that most people don't know about, is the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky
> the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky
Yep.
Chrome is even crippling some of their own APIs, like chrome.tabCapture (not available in service workers, and in mv3 will be "foreground only")
AKA, if you want to use chrome.tabCapture in mv3, you have to run it in a tab. And because that tab can be closed at any time, you need to serialize megabytes of data to the chrome.storage api every few seconds.
I'm not familiar with Adguard, but uBO Minus is meant to be a shadow of regular uBO, because it tries not to request page permissions for every website by default. Presumably, an actual MV3 version will do that and use that to at least fall back to visual blocking if request blocking is not possible.
Yeah but just granting it doesn't make it actually make use of it, no? Or are you referring to the recent update where it allows you to give permission on a per-website basis where it will do more blocking? If so, then I believe you and then it's worse than I thought.
Their stated goal is to improve the performance of the web request blocking API.
Their (unstated but suspected) goal is to neuter adblocking chrome extensions.
They should have made extensions get auto-disabled if they 'slow down web page loading too much'. Set the threshold for that to be say more than a 20% increase in page load time, but make the threshold decrease with time - eg. 10% in 2023, 5% in 2024, 2% in 2025, to finally 1% in 2026 etc.
Eventually, that would achieve both of Googles goals - since adblockers would be forced to shorten their lists of regex'es, neutering them, and performance would increase at the same time. Extension developers would have a hard time complaining, because critics will always argue they just have bloated inefficient code.
Even a very poor adblocker will speed up web page loading in the average case. If google went that route, they would be forced to confront the fact that not having an adblocker is one of the worst web performance decisions one can make.
Google get to pick the metric. They can easily choose "TotalCPU time spent by Chrome over the past week" vs "CPU time expended in the extension scripts in the past week".
Remember that whatever matric they pick must be automatically measurable by the end users machine - and loading a page with and without an ad blocker isn't that.
>They should have made extensions get auto-disabled if they 'slow down web page loading too much'. Set the threshold for that to be say more than
oh but they already did - All extensions are ignored and pushed into lower priority thread when you are starting browser and the first page loads. Everything is set to prioritize that time to first page load. Result is first page loaded when browser starts often manages to skip all adblockers.
> Their (unstated but suspected) goal is to neuter adblocking chrome extensions.
Except they didn't. There's already 3-4 adblockers that work perfectly as far as blocking ads is concerned. They do lose more advanced features, but 99.9% of people with adblockers installed never ever touch those features.
To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking.
> 99.9% of people with adblockers installed never ever touch those [advanced features]
Custom matching algorithms and ability to fine tune or expand matching algorithms according to new content blocking challenges are actually a kind of advanced feature that are used by all those users without them ever realizing it since their content blocker work seamlessly on their favorite sites without the need for intervention.
The declarativeNetRequest (DNR) API has been quite improved since it was first announced and its great, but since it's the only one we can use now, it's no longer possible to innovate by coming up with improved matching algorithm for network requests.
If the DNR had been designed 8 years ago according to the requirements of content blockers back then, it would be awfully equipped to deal with the challenges thrown at content blockers nowadays, so it's difficult to think the current one will be sufficient in the coming years.
Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome.
Obviously, extending an API is a long term commitment, so I can understand the Chrome team wanting to only do it if there is a decent benefit - "it makes my one extension with 10 users work slightly better" probably doesn't cut it.
> Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome.
- [ ] ENH,SEC,UPD: Bromite,Chromium: is there a url syntax like /path.tar.gz#sha256=cba312 that chromium http filter downloader could use to check e.g. sha256 and maybe even GPG ASC signatures with? (See also: TUF, Sigstore, W3C Blockcerts+DIDs)
>To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking.
I think it's more nuanced than that. Working around adblockers is hard right now, because there are many different types, and the ones that leverage onBeforeRequest() are the hardest to work around, and are VERY popular.
So widespread working around declarative and DNS based adblocking isn't happening, because the publishers rightly recognize it would just drive people to better adblockers.
But, once all adblockers are declarative only, it could be an effort worth taking.
Also, the Safari comparison is hard because Apple devices do many other things to shore up their adblocker. It has a larger allowed list, and comes along with everything else Apple does to protect privacy and customer-specific targeted ads.
Last, if it was really a nothingburger, I'm curious why mobile Chrome has never allowed Chrome extensions.
> Is this speculation or has there actually been an analysis of how many ads are unblockable?
You could go through all the issues that are solved on a daily basis by filter list maintainers and see how your content blocker deals with those specific issues being solved for uBO.
> I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube
I do too! But I also run into pages that are broken all the time (pages don't scroll down, entirely white/black pages load with no content, etc). This is with AdGuard's basic filter set and updated filters. uBlock Origin doesn't have these problems.
Sure, Vivaldi's AdBlocker might not be impacted a lot, but it does not matter because it is terrible anyway and it triggers every "adblock detection script" I've ever seen. While I like rest of the browser it is unusable without customised uBlock Origin.
I was hoping some company would fork Chromium before Manifest V3 change and apply patches from mainline as necessary but it seems less and less likely with every day. If Vivaldi manages to patch out Google's changes and keep uBlock working as it is now they will have me as their user until heat death of the universe.
I'm familiar with the Chromium codebase, and maintaining the Manifest web request V2 API wouldn't be a tricky patch to maintain.
Even if Google rips it all out and the supporting infrastructure, a full rewrite from scratch wouldn't be too tricky. It's just a bunch of RPC calls to the right extension process from the network stack.
You'd still have the downsides that Google is trying to get rid of (extensions can delay requests making the browser slow, and extensions aren't multithreaded so all web requests have to be funnelled through a single javascript thread in the extension). But we've lived with those downsides for 10+ years - I think we can keep them.
>extensions can delay requests making the browser slow
There's an older UBO wiki post showing, with their default set of rules, the onBeforeRequest() processing adds about 130ms of latency per request on an older i5 machine. It does also show that a less performance focused ad blocker adds around 420ms.
Of course, then you can subtract whatever performance issues loading all those ads would have caused. That math often ends up in favor of the ad blocker, even if it's not a particularly efficient one.
0.13 ms per request is loads when you consider a typical web page (facebook homepage) has about 700 requests now, and due to the single-threaded nature of javascript they all need to be processed sequentially. Ie. thats 91 milliseconds seconds of pegging one core, just for one extension, for loading one page.
It's also probably an underestimate, because it doesn't include the IPC time within Chrome, which involves at least two context switches, and the associated cache rewarming.
Granted, extensions could be better implemented - for example, for URL blocking, there should be a bloom filter for allowing stuff so that the whole list doesn't need to be checked.
>onBeforeRequest() processing adds about 130ms of latency per request
Sometimes it pays off to do some sanity checks in your head. 130ms is how long it takes for modern CPU to render 50 frames of Overwatch game. Rendering modern FPS is a LOT heavier than looking up URL in a list of 100K rules.
Which was more than enough for most of us to recommend everyone switch. Much the same was as when Firefox first came out it was unambiguously:
* A safer browser.
* A more performant browser.
Which was more than enough for most of us to recommend everyone switch. The switching cost of a browser is quite low. The next browser to meet the above criteria will experience a similar jump in users. The challenge is in actually delivering a browser that can do so. The web standards are massively complex for many reasons, some of them legitimate. The barrier for entry is going up over time and shows no sign of slowing down.
I was coaching a HS debate team when Chrome dropped and all my students switched to Chrome organically with no input from myself, a techie, within a week of release. Don't even think they were running the ads yet, there was just the web comic.
I think the biggest boost to Chrome's initial success was the fact that it's capable of installing entirely within the user profile, so unless a corporate IT department has gone out of their way to lock a system down an unprivileged user can install it for themself.
Remember, Chrome was released in 2008. Internet Explorer, with almost 2/3 of the browser marketshare, was on version 7 at that time and a stupid number of corporate IT departments would continue to default to IE 6 rather than updating or fixing their ancient garbage applications for years to come.
Chrome provided a way for power users to have a non-shitty browser, which then blossomed from there as more and more web sites made use of modern browser capabilities and worked worse and worse in corporate-mandated IE instances.
Putting on my BOFH hat obviously I'm not the biggest fan of such "shadow IT" processes but I understand that they happen when needs and wants aren't being met and sometimes this is the most effective way to force a necessary change.
Firefox’s decline has been in progress for a long time, starting when Google deployed billions of dollars of Chrome ads and pushing users of Gmail, YouTube, etc. to switch, and as people moved onto mobile devices where Firefox couldn’t run (iOS) or was at a disadvantage competing with the OS developer (everything else). Don’t forget things like the video wars where Google made a promise to drop H.264 support in the name of openness, let Firefox suffer the compatibility hit, and then retracted that promise.
Mozilla has made some bad decisions but we should acknowledge that a fair fraction of them were also flailing around trying to recover from those competitors’ actions. I don’t think Firefox OS would have happened if, for example, iOS allowed a real browser market.
My point is not that they were not struggling. But that they were (and somewhat still are) spending elsewhere in stuff barely related to Firefox and this amplify the problem. A lot of money was spent on project not really relevant that were then shelved/dump.
Personally I'd split it into two eras. The first is "Chrome arises as a faster browser and then gimps performance of Google services like Youtube on non-Chrome browsers" which lost Firefox half its market share. The second era is "Mozilla waters-down the essence of Firefox by vainly trying to recapture Chrome's market share while ignoring what its core userbase actually liked about Firefox."
Just one among many other choices. Adding garbage content like suggested stories. Removing one method of customizing the UI without implementing a new one. The pile of flaming garbage that Firefox Mobile became after the transition to Firefox for Android. Continually dropping options out of about:config and userchrome.css. It goes on and on.
Did Google gimp performance on their services or did Mozilla not spend the resources to keep up?
I can confirm that Google didn't wasn't testing on Firefox first as of the early-to-mid 2010s, but that was an efficiency-of-testing decision; how much should a company spend on testing a browser with a sub-10% market share?
For example, they created a Youtube redesign which relied on a deprecated API that only Chrome implemented. It was deliberate and resulted in a 500% slowdown for Firefox and Edge users. It was and is a systematic campaign to use Google properties to damage the user experience of competing browsers.
shrug To do my actual job, I have to implement on deprecated APIs all the time. Deprecation is a declaration of intent, but intent rams into reality and changes continuously.
There are two types of deprecated APIs: ones nobody uses and ones everybody uses. Sounds like Mozilla mis-guessed on which one of those Shadow Dom v0 would be.
(From my limited experience: I bet while the Chrome team was trying to deprecate shadow dom v0, YouTube, which still operates as a pretty independent arm inside the Google ecosystem, built a new system on Polymer and in terms of Google's management architecture, nobody has authority to tell them not to do that. Far from an intentional shafting of other browsers, it was likely a failure to coordinate internally coupled with total apathy regarding what that meant for other browsers, since from YouTube's point of view, Chrome is free and available to everyone.
Never attribute to malice that which can be explained by disorganized-bag-of-cats management style).
"Failing to see" is one explanation. "Struggling to keep pace" is another; there's really quite a lot of work involved in keeping up with web standards.
Instead of regulatory capture they are going for the standards' committee capture... I'm curious about other cases of corporations taking over standards' committees, anyone else has examples?
Well, unsurprisingly. The nature of the web ties 100% into everything Google does as a company. It's not just in their vested interest to be involved in that system; it's an existential underpinning to their company, akin to General Motor's interest in rubber standards.
Don't forget all the shady bundleware installers that tricked people into installing Chrome via Adobe Flash, Avast, etc.
https://imgur.com/gallery/WWZxj
Chromium got to be a dominant position because google nagged every user that visit google for a period of 10+ years to install chrome for a "better experience"
For at least the first half of that, it was completely true. One single change to make crashing sites stop crashing the browser.
And, despite it being google - they don’t force me into the options menu to remove advertising off of my Home Screen, and have never forcibly installed extensions advertising TV shows.
Is it? Or is the case of Mozilla innovation being suppresed by the virtue of its almost entire revenue coming from the main competitor? "Failing to see" could easilly be imposed.
There are as many project using Gecko as they are using WebKit (roughly). [1]
Browser framework that Firefox is built on is called Quantum. Other Quantum browsers are LibreWolf, Tor, Pale Moon etc..
Chrome and clones are based on Chromium.
Interestingly there is no browser framework available for WebKit rendering engine and every WebKit browser has to be built from scratch on top of WebKit.
Web rendering engine -> Browser framework -> Browser
I'd say LibreWolf, Tor, Pale Moon, etc are not browsers based on Gecko. They are forks of Firefox with some modifications.
The interface looks exactly the same.
If you look for "embedding Gecko", all the documentation seems to be archived/deprecated. It doesn't seem to be supported by Mozilla anymore. And it was never easy.
Glad to hear it. I’ve been using Vivaldi as my main browser for a while now and I’d hate to give it up, but if it’s a choice between Vivaldi and a fully functioning ad blocker I’m probably choosing the latter.
Yes, same for me. On my work laptop I use Firefox, and tried it for a few weeks without adblocker, then I gave up.
I'd love to keep Vivaldi, and when there are problems with adblocking, I will give it a patient try to see how bad it actually is, but leaving the chromium world is absolutely an option here.
Wonder how Firefox' market share will be influenced by this, in general.
Having built something that had to use the netRequest API due to new extensions being forced into MV3, I can attest to it being viciously limited and complex.
Ads will win if MV3 is mass adopted and enforced. Time to set-up Pi-hole.
Brave will probably be the only remaining chromium-based browser to have a solid adblock system that's low level enough to not be affected by the manifest changes.
Vivaldi is great and all but they suck at privacy.
This doesn't make sense, Brave and Firefox both fair well on the tests and do not break websites. Vivaldi is not a privacy focused browser so I wouldn't really put it against them but still, both Brave and Firefox do it better: Privacy and Ad-blocking.
Vivaldi is more privacy focused than any other browser. Brave collects user data [0] and Firefox gives you a unique identifier [1]. The creator of privacytest works for Brave [2]
Brave Researchers are also coming up with great privacy research every month and this isn't just re-inventing the wheel by adding adblocking or things like that. It's real privacy research work with decentralized solutions integrations: https://brave.com/privacy-updates/
> Brave collects user data [0] and Firefox gives you a unique identifier [1
Surprisingly you didn't mention your own policy:
"When you install Vivaldi browser (“Vivaldi”), each installation profile is assigned a unique user ID that is stored on your computer. Vivaldi will send a message using HTTPS directly to our servers located in Iceland every 24 hours containing this ID, version, cpu architecture, screen resolution and time since last message"
"Vivaldi includes various links to websites in the browser default bookmarks. Some of those websites are partners of Vivaldi AS and some are not. Vivaldi AS receives shared revenue from those bookmark partners."
"On desktop, Vivaldi integrates the Safe browsing API from Google, which checks the site you are visiting against a master list of known suspected phishing and malware sites. This feature can be turned off in the Privacy settings (Settings > Privacy > Privacy)."
You don't even proxy these requests to Google, which Brave does, so I'll say your claim about Vivaldi being 'more privacy focused than any other browser' is not true at all.
> The creator of privacytest works for Brave
I don't see how that makes objective information wrong?
I'll admit that I went to far with that statement (this is why I normally don't comment in these threads) but I wanted to respond to your claim that "Vivaldi is not a privacy focused browser" because it absolutely is. Not being FOSS doesn't mean that it isn't.
Pretty much every browser that isn't Chrome or Edge, has put out a similar message to Vivaldi's team. If that's not enough for Google to get their **** together, and stop pretending like they're doing this for the good of the end-user, I dunno what is.
Your "why" is exactly what selykg answered. To paraphrase: there are some people that would like the convenience to have calendar and e-mail client in their browser, just because it's already there and maybe intersects with the workflow. A niche? Maybe, but there's always someone.
In the 90s, the Internet was seen differently. The core functions - email! Shopping! Message boards! - were thought of as the pillars of what made up the World Wide Web. And so AOL and Netscape and others bundled the software into suites, where you got all your Internet stuff done. Mozilla used to be this way in its early days, before the web browser branched to Firefox.
Opera did it, too, and Vivaldi is a spiritual successor to Opera.
I switched to Vivaldi on Android because I didn't want to use Chrome, but Firefox on Android was doing two things that annoyed me: Reloading tabs when I navigate back to them after a long time ( which is a delay at best or loses the page state at worst) and as of six months ago, the screen would stutter when scrolling through pages like the New York Times.
Anyway, I tried Vivaldi mobile and liked it, then decided I might like the sync features between desktop and mobile, so I now use it on desktop.
And then I decided to try their mail client, which "just works" for me and my light usage. I already have the browser up all the time, so I hit F4 and check my mail.
Mozilla was like this too because it was (initially) the open sourced Netscape code, at least until they decided to throw most of it away and start over.
> I also wouldn't buy a fridge that had a built-in toaster.
Storing food and transforming food are not the same activity.
However, "trivection" ovens that use 3 kinds of eat and also microwave or toast are increasingly popular, because people very much like one thing that does several related things. (EDIT: Same story as the water + ice you agreed with below.)
"Get my stuff that's online" or "do things online" is one of those same-headspace things large percentages of boomers grew up doing in one place (AOL, then Mozilla suite, Opera, etc.), and "portals" perpetuated today by Google and Microsoft except as web apps in browsers (Edge, Chrome) trying to be the portal wrapping the web apps, which the same people tend to hate.
So Vivaldi gives the "one place" that works "one way" but doesn't feel like a weird web app you accidentally close a tab and lose everything.
>As Vivaldi is built on the Chromium code, how we tackle the API change depends on how Google implements the restriction. The assurance is, whatever restrictions Google adds, in the end, we’ll look into removing them.
Is this not a serious wake up call for all these companies relying on Chromium? You are staking so much of your business on a giant conglomerate that does not care about you or your users, whose only aim to sweep up as much data from the web as possible to feed their ad machine.
It's not really a wake up call - at any time they could fork and go their own way.
Just right now, they prefer to not have to pay for 1000+ engineers to work on the codebase to keep up with the pace that Google manages.
I'm not sure a lot of these browsers have the resources to fork Chromium and stay "profitable" or whatever their goal is. Microsoft probably could but they gave up on Edge when it was pretty feature complete so I'm guessing that they would really prefer not to maintain a browser by themselves. I'd bet that most of the other Chromium-based browsers would not be capable of financially maintaining a serious fork where some fundamental internal APIs have been changed.
Microsoft had a chance of winning back Browser war by announcing Blink fork with V2 and 100% backporting of all Google changes. But "Microsoft reported more than $10 billion in advertising revenue last year", so they were reluctant to get this easy win.
Yes, I was pretty disappointed when Microsoft announced they would transition to v3. They already do so much customization to completely de-Google Chromium and replace it with Microsoft equivalent functionality (and adding new features on top of that) - it would have been almost a no-op for them to maintain v2 compatibility.
I think Microsoft is increasingly getting into the ad business themselves, and so may have the same incentive as Google in terms of neutering adblockers.
I don't think it's a preference thing. I don't think Vivaldi, or Brave, or any other company whose main product is a browser, can have the income to pay 1000+ engineers to work on the codebase to keep up with the pace of Google.
Maybe it should at the very least be a wake up call to companies which can't afford the engineer-hours it takes to maintain a Chromium fork.
There's enough of them and I am sure non-affiliated as well, they could likely scrape together enough engineering 'power' to maintain their own sane fork of Chromium.
They don't need to keep pace feature-wise. I don't need a featureful browser, I want a browser that performs well.
>They don't need to keep pace feature-wise.
Last I looked into it; the problem wasnt with features. The Chrome code base is very dynamic and if you fall behind then it becomes very hard to pull upstream patches due to the pace at which things get refactored.
Mozilla (and Opera for that matter before) showed that one needed much smaller team to maintain a full-featured web engine. Plus a lot of Chromium complexity comes from the desire to make such big team manageable. So they split tightly coupled code into separated components worked on by different groups resulting in a lot of glue interfaces and wrapper classes.
Former Mozilla engineer here: The Firefox team isn't as small as you are implying, and they are always constrained by inadequate resources.
Out of curiosity, does Google really have that many engineers working on Chromium? According to Wikipedia, Mozilla has ~750 employees and only a subset of those are working on Firefox.
The repository gets 500 commits per day. Assume the average engineer manages about 1 commit per day. Thats about 500 engineers working on it... [very rough, but ballpark correct].
And remember some people might be working on experiments/research/ideas that never make it into the repo.
And there are lots of libraries in other repos that kinda only exist for Chromium that Google also works on - eg. the Skia graphics library.
But... on top of those engineers will be UX designers, managers, HR, finance, chefs, and all the other people who make an organisation work.
I think 1000 is a good guess - maybe even 2000.
Former Mozilla employee here: A subset, yes, but also a majority. And it isn't enough.
> keep up with the pace that Google manages.
Absent security issues, what's the value of the last N releases of Chrome? How far do you have to go to get something of value that changed?
Serious question, because I'm not on the cutting edge of browser technology. From a step away, it seems like it's been fairly stable.
> Absent security issues, what's the value of the last N releases of Chrome? How far do you have to go to get something of value that changed?
IMO something of value changes with every release. For example, in the most recent release (105) Chromium gained support for container queries and the :has() pseudo-class. Container queries allow web devs to change how styling is applied the contents of an element based on the size of the element itself. That's a major new tool for web developers & designers. 105 also supports the HTML Sanitizer API, which relieves the need to use libraries like DomPurify to protect against XSS attacks.
If you're interested in digging into what changes in each release, Chrome has a blog post series called New in Chrome[1] that summarizes changes. And to dive even further into changes, the Chrome Status[2] site allows you to filter platform feature changes by release milestone.
[1]: https://developer.chrome.com/tags/new-in-chrome/ [2]: https://chromestatus.com/features#milestone%3D104
Former browser engineer here: Thank you for that second sentence. So many people forget that part!
They could fork and alter only this part of the code and likely manage pulling from upstream with very few people.
Even easier if there's a shared open source fork. My company did it with 2 people
IMO this is a great chance for Microsoft to take charge and try to get back in the browser game.
They should fork Chromium and sign up all the others (Brave, Vivaldi, Opera) to help maintain the code base. Of course MS can afford to pitch in the maximum amount of resources, both human and financial.
This way we will have a serious contender to Chrome in the industry and they can differentiate themselves meaningfully from Google's hegemony in the space.
But they won't do it, it's hard to ignore those sweet potential ad monies.
>Microsoft reported more than $10 billion in advertising revenue last year
It would have been good for the ecosystem to spin up around Firefox or WebKit, either would have been a less problematic entity than Blink.
Microsoft should have based Edge on Mozilla's engine instead of blink, and should not have tried to get Mozilla to move to blink
The first problem with your (and a lot of peoples') proposal is the notion that a Chrome ripoff (aka a fork) is a valid competitor.
If you're going to sell me a Chrome ripoff, I'll just use the real deal. It's the same reason why Firefox died: They tried/try to ripoff Chrome, and as a result everyone just moved/moves over to the real deal.
I'm curious about the notion that Firefox tried to ripoff Chrome. I have qualms with Firefox, but that wasn't on the list.
I think he may be talking about the UI. Firefox's UI changes were very Chrome-like.
On the other hand, I use Vivaldi fairly successfully when some site demands I use Chrome instead of Firefox. Most people won't of course, but it is a valid option.
I'm confused by both your assertion Firefox is dead and that they tried to rip off Chrome. Can you clarify?
I'm using Firefox specifically for a number of features chrome does not have.
>assertion Firefox is dead
Firefox is (and has been) no longer a consideration in web development because of its tiny and thus inconsequential market share.
Lest we forget, Firefox was once the market leader that usurped the position from IE6.
>they tried to rip off Chrome
The constant dumbing down and changing of the UI, removal of XUL in favor of WebAssembly (dropping Firefox extensions in favor of becoming compatible with Chrome extensions), moving to the Chrome Version Number system (we're on Firefox what again? 100? 150? 200?) to not look ancient comparatively, etc.
I'm sincerely of the opinion Mozilla should just drop Gecko and move Firefox over to being another Chrome fork. It would be far more in line with Mozilla's goals of shipping a Chrome ripoff in vain attempts to steal Chrome users.
> Firefox is (and has been) no longer a consideration in web development because of its tiny and thus inconsequential market share.
Is 7.4% of desktop users [0] inconsequential? Maybe to your business, but I think most would be sad to lose 7% of desktop users. I'll also note if this indicates "death" Safari is dead too.
I know XUL pissed off a lot of people, but I really don't think copying Chrome was the main motivation. XUL had a LOT of cruft and issues they wanted to escape and going to web extensions for some level of interoperability made sense, and looking at data from around that time [1] it doesn't appear to have cost them much of their user-base. It's also a perfect example of Firefox not copying Chrome, with Firefox supporting a ton of APIs Chrome doesn't or has removed [2].
As for the UI "copying" Chrome, I'm not sure how to respond to that. I just spun up vanilla profiles of Firefox and Chrome, and sure they both have tabs at the top, but they are pretty visually distinct. Yes Firefox has reduced the size of it's UI over the years, but if that's copying Chrome... I guess a lot of apps are.
Firefox may be in decline, and that makes me sad, but I think that has a lot more to do with shitty developers using non-standard Chrome APIs and then telling users to use Chrome when it breaks, while GMail and other Google properties cripple Firefox performance, rather than Firefox blindly copying Chrome.
Personally I hope this trend reverses. Firefox is the only thing stopping Chrome from becoming the next IE 6.
[0] - https://gs.statcounter.com/browser-market-share/desktop/worl...
[1] - https://gs.statcounter.com/browser-market-share/desktop/worl...
[2] - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
>Is 7.4% of desktop users [0] inconsequential? Maybe to your business, but I think most would be sad to lose 7% of desktop users. I'll also note if this indicates "death" Safari is dead too.
Nobody with a sane mind is going to bother spending time and resources on just 7.4% of the userbase, that's just a simple and brutal fact of reality.
I do think Safari is "dead" as a browser, it's not Chrome after all. But it's not dead dead yet, and the only reason for that is because it's the only browser on iOS which itself holds a significant minority share of the mobile space. Webdevs will support Safari not because Safari is worth paying attention to, but because iOS and its ~45%(?) market share is worth paying attention to.
>Personally I hope this trend reverses. Firefox is the only thing stopping Chrome from becoming the next IE 6.
I argue Chrome is already the second coming of IE6, and we've yet to see the second coming of Firefox. And whatever the second of coming of Firefox is, it's almost certainly not going to be anything to do with Mozilla.
I'm genuinely curious what industry your in that losing ~10% of your user-base would be anything short of disaster.
Or they (Brave, Vivaldi, Opera, etc) could use G̵e̵c̵k̵o̵ Quantum instead of Chromium.
If that happens I suspect they would lose a large portion of their userbase to Firefox. The main selling point for a lot of people is that these browsers are basically Chrome without the Google stuff. If they change to Quantum, why would people not just use Firefox? Unlike Chrome, Firefox is already fairly privacy focused, there's not as much of an incentive for people to use alternative Firefox-based browsers.
I currently use Brave, but if they switched to using Quantum I personally would just switch to Firefox proper.
> They should fork Chromium
Microsoft already did that. Edge uses Microsoft’s fork of Chromium.
Edge isn't a fork, it's just a Chromium browser. All of the horrible changes Google makes to Chromium affect Edge too
You’re wrong. Microsoft maintains a fork and continuously decides which changes to pull from Chromium’s source.
It's not a fork. They have to go out of their way to exclude changes from chromium https://www.reddit.com/r/IAmA/comments/c094uf/hi_reddit_were...
> In general, the idea is that Edge developers check in their code to the internal Main branch. Code from Microsoft employees is joined by code pulled by the “pump” from the upstream Chromium project, with various sheriffs working around the clock to fix any merge conflicts between the upstream code pumped in and the code Microsoft engineers have added.
Source: https://textslashplain.com/2022/08/04/understanding-browser-...
Microsoft have their own branch, where they add Edge-specific changes, and they regularly pull changes from the Chromium source (probably not all changes) and merge them to their branch. If you don’t consider this a fork, then please explain why.
Forks diverge. Blink is a fork of Webkit, but Blink hardly resembles Webkit anymore. Blink doesn't pull any changes from Webkit
https://en.wikipedia.org/wiki/Fork_(software_development)
>Eric S. Raymond, in his essay Homesteading the Noosphere,[12] stated that "The most important characteristic of a fork is that it spawns competing projects that cannot later exchange code, splitting the potential developer community"
At this point I just want to add that I'm not a developer and I don't actually know much, I just read stuff online. But yeah, Edge isn't a fork
Also from that Wikipedia article:
> Distributed revision control (DVCS) tools have popularised a less emotive use of the term "fork", blurring the distinction with "branch".[14] With a DVCS such as Mercurial or Git, the normal way to contribute to a project, is to first create a personal branch of the repository, independent of the main repository, and later seek to have your changes integrated with it. Sites such as GitHub, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced, and GitHub uses "fork" as its term for this method of contribution to a project.
On GitHub, if you fork somebody else’s repo, your version is called a fork. You don’t have to diverge. You don’t have to merge. You don’t have to do anything, but it’s still called a fork. Do you agree that this is how GitHub uses the term fork?
Yes, that's how GitHub calls it, but by calling everything a fork the term loses its meaning. By this definition every Chromium browser is a fork, which is just ridiculous. Edge's developers don't think of Edge as a fork
It is hard to over-state the impact that MV3 will have on the current extension landscape!
This move is a blatant attack from Google on power-users, always in the name of "security" and performance.
Google announced that in order to achieve security we must get rid of all "remote code" execution avenues.
Really small print: "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google.
> "Remote code" being all code Remote to Google, as in code not residing on Google servers. User code sitting on Users disk in form of an extension installed Locally by the User into his "User Agent" is "Remote code" to Google.
Replace Google with Mozilla, and you still have an accurate statement:
https://github.com/mozilla-mobile/fenix/issues/20647
I don't even think you can say adblockers are a "power user" feature. The web is so bloated and bad that it's virtually unusable without it.
I hope this gets found as the anti-competitive move that it is. They're taking advantage of their near-monopoly that they have in the browser space to force people to view more of their own ads. It's disgusting.
Adblocking is the tip of the iceburg. Proxying, dev-tools that manipulate CORS, rule-based cosmetic filters etc... will also be impacted.
The other huge change that most people don't know about, is the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky
> the move from a persistent background.js script to a sevice-worker will just make a number of use-cases impossible or very hacky
Yep.
Chrome is even crippling some of their own APIs, like chrome.tabCapture (not available in service workers, and in mv3 will be "foreground only")
AKA, if you want to use chrome.tabCapture in mv3, you have to run it in a tab. And because that tab can be closed at any time, you need to serialize megabytes of data to the chrome.storage api every few seconds.
Yet lots of people seem to manage, e.g. by stating that adblockers will cease to function entirely.
I have tried both uBlock Minus[0] and AdguardMV3[1] and can confidently say that they're barely a shadow of their manifest-v2 versions.
[0] https://github.com/gorhill/uBlock/tree/master/platform/mv3
[1] https://github.com/AdguardTeam/AdGuardMV3
I'm not familiar with Adguard, but uBO Minus is meant to be a shadow of regular uBO, because it tries not to request page permissions for every website by default. Presumably, an actual MV3 version will do that and use that to at least fall back to visual blocking if request blocking is not possible.
You can easily tweak the manifest.json to grant the extension permissions on all urls.
Give it a shot and see that it still falls behind and doesn't block much of the annoyances.
Yeah but just granting it doesn't make it actually make use of it, no? Or are you referring to the recent update where it allows you to give permission on a per-website basis where it will do more blocking? If so, then I believe you and then it's worse than I thought.
You don't have to believe me, you can try my fork pre-built here
https://github.com/raed667/uBlock-minus-mv3-cs-poc/releases/...
Google made a faux-pas with this one...
Their stated goal is to improve the performance of the web request blocking API.
Their (unstated but suspected) goal is to neuter adblocking chrome extensions.
They should have made extensions get auto-disabled if they 'slow down web page loading too much'. Set the threshold for that to be say more than a 20% increase in page load time, but make the threshold decrease with time - eg. 10% in 2023, 5% in 2024, 2% in 2025, to finally 1% in 2026 etc.
Eventually, that would achieve both of Googles goals - since adblockers would be forced to shorten their lists of regex'es, neutering them, and performance would increase at the same time. Extension developers would have a hard time complaining, because critics will always argue they just have bloated inefficient code.
Even a very poor adblocker will speed up web page loading in the average case. If google went that route, they would be forced to confront the fact that not having an adblocker is one of the worst web performance decisions one can make.
Google get to pick the metric. They can easily choose "TotalCPU time spent by Chrome over the past week" vs "CPU time expended in the extension scripts in the past week".
Remember that whatever matric they pick must be automatically measurable by the end users machine - and loading a page with and without an ad blocker isn't that.
Ah, the boiling frog strategy. Effective but definitely evil.
Is "don't be evil" still part of the Google's official ethos?
>Is "don't be evil" still part of the Google's official ethos?
No it is not, and has not been for decades
It no longer prefaces the code of conduct but it still has a mention.
https://en.m.wikipedia.org/wiki/Don%27t_be_evil
>They should have made extensions get auto-disabled if they 'slow down web page loading too much'. Set the threshold for that to be say more than
oh but they already did - All extensions are ignored and pushed into lower priority thread when you are starting browser and the first page loads. Everything is set to prioritize that time to first page load. Result is first page loaded when browser starts often manages to skip all adblockers.
eWASM opcodes each have a real cost. It's possible to compile {JS, TypeScript, C, Python} to WASM.
What are some ideas for UI Visual Affordances to solve for bad UX due to slow browser tabs and extensions?
- [ ] UBY: Browsers: Strobe the tab tab or extension button when it's beyond (configurable) resource usage thresholds
- [ ] UBY: Browsers: Vary the {color, size, fill} of the tab tabs according to their relative resource utilization
- [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU, RAM, Disk, [GPU, TPU, QPU] (Linux: cgroups,)
> Their (unstated but suspected) goal is to neuter adblocking chrome extensions.
Except they didn't. There's already 3-4 adblockers that work perfectly as far as blocking ads is concerned. They do lose more advanced features, but 99.9% of people with adblockers installed never ever touch those features.
To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking.
> 99.9% of people with adblockers installed never ever touch those [advanced features]
Custom matching algorithms and ability to fine tune or expand matching algorithms according to new content blocking challenges are actually a kind of advanced feature that are used by all those users without them ever realizing it since their content blocker work seamlessly on their favorite sites without the need for intervention.
The declarativeNetRequest (DNR) API has been quite improved since it was first announced and its great, but since it's the only one we can use now, it's no longer possible to innovate by coming up with improved matching algorithm for network requests.
If the DNR had been designed 8 years ago according to the requirements of content blockers back then, it would be awfully equipped to deal with the challenges thrown at content blockers nowadays, so it's difficult to think the current one will be sufficient in the coming years.
Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome.
Obviously, extending an API is a long term commitment, so I can understand the Chrome team wanting to only do it if there is a decent benefit - "it makes my one extension with 10 users work slightly better" probably doesn't cut it.
> Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome.
This is not at all how API proposals are handled. There are a lot more (time, financial, logical) barriers to a change like this. See the role of the W3C in this: https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-p...
It is reasonable to expect BPF or a BPF-like filter. https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
bromite/build/patches/Bromite-AdBlockUpdaterService.patch: https://github.com/bromite/bromite/blob/master/build/patches...
bromite/build/patches/disable-AdsBlockedInfoBar.patch: https://github.com/bromite/bromite/blob/master/build/patches...
bromite/build/patches/Bromite-auto-updater.patch: () https://github.com/bromite/bromite/blob/master/build/patches...
- [ ] ENH,SEC,UPD: Bromite,Chromium: is there a url syntax like /path.tar.gz#sha256=cba312 that chromium http filter downloader could use to check e.g. sha256 and maybe even GPG ASC signatures with? (See also: TUF, Sigstore, W3C Blockcerts+DIDs)
Bromite/build/patches/Re-introduce-*.patch: [...]
>To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking.
I think it's more nuanced than that. Working around adblockers is hard right now, because there are many different types, and the ones that leverage onBeforeRequest() are the hardest to work around, and are VERY popular.
So widespread working around declarative and DNS based adblocking isn't happening, because the publishers rightly recognize it would just drive people to better adblockers.
But, once all adblockers are declarative only, it could be an effort worth taking.
Also, the Safari comparison is hard because Apple devices do many other things to shore up their adblocker. It has a larger allowed list, and comes along with everything else Apple does to protect privacy and customer-specific targeted ads.
Last, if it was really a nothingburger, I'm curious why mobile Chrome has never allowed Chrome extensions.
This isn't an advanced feature, it's just how to effectively block modern ads and ad networks will just rely on techniques that can't be blocked now.
Is this speculation or has there actually been an analysis of how many ads are unblockable?
I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube
Just sounds like a bunch of speculative hysteria tbh.
> Is this speculation or has there actually been an analysis of how many ads are unblockable?
You could go through all the issues that are solved on a daily basis by filter list maintainers and see how your content blocker deals with those specific issues being solved for uBO.
---
[1] https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+...
> I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube
I do too! But I also run into pages that are broken all the time (pages don't scroll down, entirely white/black pages load with no content, etc). This is with AdGuard's basic filter set and updated filters. uBlock Origin doesn't have these problems.
Which declarative ad blocker?
There was tons of complaining when Safari adopted those restrictions with the same claims and fears that ad blockers were dead forever.
Sure, Vivaldi's AdBlocker might not be impacted a lot, but it does not matter because it is terrible anyway and it triggers every "adblock detection script" I've ever seen. While I like rest of the browser it is unusable without customised uBlock Origin.
I was hoping some company would fork Chromium before Manifest V3 change and apply patches from mainline as necessary but it seems less and less likely with every day. If Vivaldi manages to patch out Google's changes and keep uBlock working as it is now they will have me as their user until heat death of the universe.
I'm familiar with the Chromium codebase, and maintaining the Manifest web request V2 API wouldn't be a tricky patch to maintain.
Even if Google rips it all out and the supporting infrastructure, a full rewrite from scratch wouldn't be too tricky. It's just a bunch of RPC calls to the right extension process from the network stack.
You'd still have the downsides that Google is trying to get rid of (extensions can delay requests making the browser slow, and extensions aren't multithreaded so all web requests have to be funnelled through a single javascript thread in the extension). But we've lived with those downsides for 10+ years - I think we can keep them.
>extensions can delay requests making the browser slow
There's an older UBO wiki post showing, with their default set of rules, the onBeforeRequest() processing adds about 130ms of latency per request on an older i5 machine. It does also show that a less performance focused ad blocker adds around 420ms.
https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-effic...
Of course, then you can subtract whatever performance issues loading all those ads would have caused. That math often ends up in favor of the ad blocker, even if it's not a particularly efficient one.
0.13 ms per request is loads when you consider a typical web page (facebook homepage) has about 700 requests now, and due to the single-threaded nature of javascript they all need to be processed sequentially. Ie. thats 91 milliseconds seconds of pegging one core, just for one extension, for loading one page.
It's also probably an underestimate, because it doesn't include the IPC time within Chrome, which involves at least two context switches, and the associated cache rewarming.
Granted, extensions could be better implemented - for example, for URL blocking, there should be a bloom filter for allowing stuff so that the whole list doesn't need to be checked.
>onBeforeRequest() processing adds about 130ms of latency per request
Sometimes it pays off to do some sanity checks in your head. 130ms is how long it takes for modern CPU to render 50 frames of Overwatch game. Rendering modern FPS is a LOT heavier than looking up URL in a list of 100K rules.
It costs 0.130ms or 130μs, not 130ms.
Yeah... relying on Chromium and "don't be evil" Google definitely sounds like fun.
It's sad that Firefox engine is so difficult to embed and we could have seen more projects using it.
The history of how Chromium got to such a dominant position is basically a history of Mozilla failing to see the next thing over the horizon.
Yes, it's due to Mozilla failing to keep up.
Possibly Google paying companies to bundle Chrome with their software installers had a part as well.
Perhaps putting a Chrome advertisement to the Google homepage and recommending an "upgrade" to all Google visitors played a part too. Maybe.
When Chrome came out it was unambiguously:
* A safer browser. * A more performant browser.
Which was more than enough for most of us to recommend everyone switch. Much the same was as when Firefox first came out it was unambiguously:
* A safer browser. * A more performant browser.
Which was more than enough for most of us to recommend everyone switch. The switching cost of a browser is quite low. The next browser to meet the above criteria will experience a similar jump in users. The challenge is in actually delivering a browser that can do so. The web standards are massively complex for many reasons, some of them legitimate. The barrier for entry is going up over time and shows no sign of slowing down.
I was coaching a HS debate team when Chrome dropped and all my students switched to Chrome organically with no input from myself, a techie, within a week of release. Don't even think they were running the ads yet, there was just the web comic.
I think the biggest boost to Chrome's initial success was the fact that it's capable of installing entirely within the user profile, so unless a corporate IT department has gone out of their way to lock a system down an unprivileged user can install it for themself.
Remember, Chrome was released in 2008. Internet Explorer, with almost 2/3 of the browser marketshare, was on version 7 at that time and a stupid number of corporate IT departments would continue to default to IE 6 rather than updating or fixing their ancient garbage applications for years to come.
Chrome provided a way for power users to have a non-shitty browser, which then blossomed from there as more and more web sites made use of modern browser capabilities and worked worse and worse in corporate-mandated IE instances.
Putting on my BOFH hat obviously I'm not the biggest fan of such "shadow IT" processes but I understand that they happen when needs and wants aren't being met and sometimes this is the most effective way to force a necessary change.
It's not Mozilla failing to keep up, it's Mozilla growing an unhealthy, greedy and complacent middle-management fat.
Firefox’s decline has been in progress for a long time, starting when Google deployed billions of dollars of Chrome ads and pushing users of Gmail, YouTube, etc. to switch, and as people moved onto mobile devices where Firefox couldn’t run (iOS) or was at a disadvantage competing with the OS developer (everything else). Don’t forget things like the video wars where Google made a promise to drop H.264 support in the name of openness, let Firefox suffer the compatibility hit, and then retracted that promise.
Mozilla has made some bad decisions but we should acknowledge that a fair fraction of them were also flailing around trying to recover from those competitors’ actions. I don’t think Firefox OS would have happened if, for example, iOS allowed a real browser market.
My point is not that they were not struggling. But that they were (and somewhat still are) spending elsewhere in stuff barely related to Firefox and this amplify the problem. A lot of money was spent on project not really relevant that were then shelved/dump.
Personally I'd split it into two eras. The first is "Chrome arises as a faster browser and then gimps performance of Google services like Youtube on non-Chrome browsers" which lost Firefox half its market share. The second era is "Mozilla waters-down the essence of Firefox by vainly trying to recapture Chrome's market share while ignoring what its core userbase actually liked about Firefox."
How did Mozilla "water-down" their own essence? Is it about that old XUL debate again?
Just one among many other choices. Adding garbage content like suggested stories. Removing one method of customizing the UI without implementing a new one. The pile of flaming garbage that Firefox Mobile became after the transition to Firefox for Android. Continually dropping options out of about:config and userchrome.css. It goes on and on.
All of those are niche features that will not hold back the tide of Chrome
Precisely, but they will help alienate Firefox's core fanbase.
Did Google gimp performance on their services or did Mozilla not spend the resources to keep up?
I can confirm that Google didn't wasn't testing on Firefox first as of the early-to-mid 2010s, but that was an efficiency-of-testing decision; how much should a company spend on testing a browser with a sub-10% market share?
For example, they created a Youtube redesign which relied on a deprecated API that only Chrome implemented. It was deliberate and resulted in a 500% slowdown for Firefox and Edge users. It was and is a systematic campaign to use Google properties to damage the user experience of competing browsers.
So Mozilla didn't implement a deprecated API that would have made video 500% faster on the largest video site on the planet.
... That sounds like it's on Mozilla.
no. its called deprecated API for a reason.
Its deprecated
shrug To do my actual job, I have to implement on deprecated APIs all the time. Deprecation is a declaration of intent, but intent rams into reality and changes continuously.
There are two types of deprecated APIs: ones nobody uses and ones everybody uses. Sounds like Mozilla mis-guessed on which one of those Shadow Dom v0 would be.
(From my limited experience: I bet while the Chrome team was trying to deprecate shadow dom v0, YouTube, which still operates as a pretty independent arm inside the Google ecosystem, built a new system on Polymer and in terms of Google's management architecture, nobody has authority to tell them not to do that. Far from an intentional shafting of other browsers, it was likely a failure to coordinate internally coupled with total apathy regarding what that meant for other browsers, since from YouTube's point of view, Chrome is free and available to everyone.
Never attribute to malice that which can be explained by disorganized-bag-of-cats management style).
"Failing to see" is one explanation. "Struggling to keep pace" is another; there's really quite a lot of work involved in keeping up with web standards.
And, surprisingly, Google has more employees on WICG (the W3C standards incubator) than all other relevant parties added together.
Instead of regulatory capture they are going for the standards' committee capture... I'm curious about other cases of corporations taking over standards' committees, anyone else has examples?
Most standards committees are either built from or heavily influenced by the corporate interests that are directly impacted by the standards.
Not really surprising given that W3c is basically a subsidiary of Google at this point rubber-stamping any change to "standards" that google wants
Well, unsurprisingly. The nature of the web ties 100% into everything Google does as a company. It's not just in their vested interest to be involved in that system; it's an existential underpinning to their company, akin to General Motor's interest in rubber standards.
That is also true of Mozilla and Facebook, and probably others...
Don't forget all the shady bundleware installers that tricked people into installing Chrome via Adobe Flash, Avast, etc. https://imgur.com/gallery/WWZxj
Chromium got to be a dominant position because google nagged every user that visit google for a period of 10+ years to install chrome for a "better experience"
For at least the first half of that, it was completely true. One single change to make crashing sites stop crashing the browser.
And, despite it being google - they don’t force me into the options menu to remove advertising off of my Home Screen, and have never forcibly installed extensions advertising TV shows.
Is it? Or is the case of Mozilla innovation being suppresed by the virtue of its almost entire revenue coming from the main competitor? "Failing to see" could easilly be imposed.
It's not even that. They had innovative things (arguably before the world was ready) and cancelled them.
Fun facts:
There are as many project using Gecko as they are using WebKit (roughly). [1]
Browser framework that Firefox is built on is called Quantum. Other Quantum browsers are LibreWolf, Tor, Pale Moon etc..
Chrome and clones are based on Chromium.
Interestingly there is no browser framework available for WebKit rendering engine and every WebKit browser has to be built from scratch on top of WebKit.
Web rendering engine -> Browser framework -> Browser
Blink -> Chromium -> Chrome, Edge, ...
Gecko -> Quantum -> Firefox, LibreWolf, ...
WebKit -> -> Safari, Orion, ...
[1] https://twitter.com/vladquant/status/1492181669788356611/pho...
I'd say LibreWolf, Tor, Pale Moon, etc are not browsers based on Gecko. They are forks of Firefox with some modifications.
The interface looks exactly the same.
If you look for "embedding Gecko", all the documentation seems to be archived/deprecated. It doesn't seem to be supported by Mozilla anymore. And it was never easy.
They are forks of Quantum browser framework of which Firefox is one instance, like Chrome is one instance of "Chromium" browser framework.
Pale Moon is not Quantum.
> It's sad that Firefox engine is so difficult to embed and we could have seen more projects using it.
Not on Android, it isn't. https://geckoview.dev
Or that Rust based renderer they were working on.
As far as I'm aware they integrated Servo into Firefox piece by piece.
I looked. FF >92 is using Quantum Render. It also seems there is a possibility to embed it.
Glad to hear it. I’ve been using Vivaldi as my main browser for a while now and I’d hate to give it up, but if it’s a choice between Vivaldi and a fully functioning ad blocker I’m probably choosing the latter.
Yes, same for me. On my work laptop I use Firefox, and tried it for a few weeks without adblocker, then I gave up.
I'd love to keep Vivaldi, and when there are problems with adblocking, I will give it a patient try to see how bad it actually is, but leaving the chromium world is absolutely an option here.
Wonder how Firefox' market share will be influenced by this, in general.
I'm curious why you used Firefox without ublock origin?
Having built something that had to use the netRequest API due to new extensions being forced into MV3, I can attest to it being viciously limited and complex.
Ads will win if MV3 is mass adopted and enforced. Time to set-up Pi-hole.
Brave will probably be the only remaining chromium-based browser to have a solid adblock system that's low level enough to not be affected by the manifest changes.
Vivaldi is great and all but they suck at privacy.
Source: https://privacytests.org
https://vivaldi.com/is/security/common-questions/#privacytes...
This doesn't make sense, Brave and Firefox both fair well on the tests and do not break websites. Vivaldi is not a privacy focused browser so I wouldn't really put it against them but still, both Brave and Firefox do it better: Privacy and Ad-blocking.
Vivaldi is more privacy focused than any other browser. Brave collects user data [0] and Firefox gives you a unique identifier [1]. The creator of privacytest works for Brave [2]
Full disclosure, I work at Vivaldi.
0. https://search.brave.com/help/usage-metrics
1. https://support.mozilla.org/en-US/kb/desktop-attribution-pri...
2. https://privacytests.org/about.html
> Vivaldi is more privacy focused than any other browser.
Yeah, no. Sorry, You're not even fully FOSS.
Brave is the most private mainstream browser. Here's an independent research paper from Trinity College, Dublin about it: https://www.scss.tcd.ie/Doug.Leith/pubs/browser_privacy.pdf
Brave Researchers are also coming up with great privacy research every month and this isn't just re-inventing the wheel by adding adblocking or things like that. It's real privacy research work with decentralized solutions integrations: https://brave.com/privacy-updates/
> Brave collects user data [0] and Firefox gives you a unique identifier [1
Surprisingly you didn't mention your own policy: "When you install Vivaldi browser (“Vivaldi”), each installation profile is assigned a unique user ID that is stored on your computer. Vivaldi will send a message using HTTPS directly to our servers located in Iceland every 24 hours containing this ID, version, cpu architecture, screen resolution and time since last message"
"Vivaldi includes various links to websites in the browser default bookmarks. Some of those websites are partners of Vivaldi AS and some are not. Vivaldi AS receives shared revenue from those bookmark partners."
"On desktop, Vivaldi integrates the Safe browsing API from Google, which checks the site you are visiting against a master list of known suspected phishing and malware sites. This feature can be turned off in the Privacy settings (Settings > Privacy > Privacy)."
You don't even proxy these requests to Google, which Brave does, so I'll say your claim about Vivaldi being 'more privacy focused than any other browser' is not true at all.
> The creator of privacytest works for Brave
I don't see how that makes objective information wrong?
I'll admit that I went to far with that statement (this is why I normally don't comment in these threads) but I wanted to respond to your claim that "Vivaldi is not a privacy focused browser" because it absolutely is. Not being FOSS doesn't mean that it isn't.
not just ad blocking, user scripts are going away too.
Next year is going to be the year of Firefox. Mozilla team intend to keep these APIs around.
It looks like it's being worked on, see <https://github.com/w3c/webextensions/issues/279>.
Pretty much every browser that isn't Chrome or Edge, has put out a similar message to Vivaldi's team. If that's not enough for Google to get their **** together, and stop pretending like they're doing this for the good of the end-user, I dunno what is.
> Vivaldi comes with [...] a built-in Mail and Calendar
Why? Why on earth would anyone want those built into their web browser?
Vivaldi is sort of the spiritual successor to Opera and Opera had those things built in and by the sounds of it, some people really enjoyed that.
Just because you might not be interested does not mean others aren't.
I get that, but that doesn't really answer the "why". I also wouldn't buy a fridge that had a built-in toaster.
How about a gaming console with a built-in chicken warmer? https://landing.coolermaster.com/kfconsole/
Now we're talking.
Your "why" is exactly what selykg answered. To paraphrase: there are some people that would like the convenience to have calendar and e-mail client in their browser, just because it's already there and maybe intersects with the workflow. A niche? Maybe, but there's always someone.
I guess the thing that's baffling me then is how they got there in the first place.
In the 90s, the Internet was seen differently. The core functions - email! Shopping! Message boards! - were thought of as the pillars of what made up the World Wide Web. And so AOL and Netscape and others bundled the software into suites, where you got all your Internet stuff done. Mozilla used to be this way in its early days, before the web browser branched to Firefox.
Opera did it, too, and Vivaldi is a spiritual successor to Opera.
I switched to Vivaldi on Android because I didn't want to use Chrome, but Firefox on Android was doing two things that annoyed me: Reloading tabs when I navigate back to them after a long time ( which is a delay at best or loses the page state at worst) and as of six months ago, the screen would stutter when scrolling through pages like the New York Times.
Anyway, I tried Vivaldi mobile and liked it, then decided I might like the sync features between desktop and mobile, so I now use it on desktop.
And then I decided to try their mail client, which "just works" for me and my light usage. I already have the browser up all the time, so I hit F4 and check my mail.
Mozilla was like this too because it was (initially) the open sourced Netscape code, at least until they decided to throw most of it away and start over.
How about a water dispenser and ice machine?
Mail and Calendar apps are mostly used from the browser now anwyay.
Cold water and ice being dispensed from a thing that makes things cold? Makes sense.
> I also wouldn't buy a fridge that had a built-in toaster.
Storing food and transforming food are not the same activity.
However, "trivection" ovens that use 3 kinds of eat and also microwave or toast are increasingly popular, because people very much like one thing that does several related things. (EDIT: Same story as the water + ice you agreed with below.)
"Get my stuff that's online" or "do things online" is one of those same-headspace things large percentages of boomers grew up doing in one place (AOL, then Mozilla suite, Opera, etc.), and "portals" perpetuated today by Google and Microsoft except as web apps in browsers (Edge, Chrome) trying to be the portal wrapping the web apps, which the same people tend to hate.
So Vivaldi gives the "one place" that works "one way" but doesn't feel like a weird web app you accidentally close a tab and lose everything.
Zawinski's Law. [1]
[1]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_La...
Emacs has a mail reader.
Why would anyone want a mail reader in their editor. /s
Why not?
Because I can access email online and my OS has a built in calendar
Vivaldi really needs its own extension store.
What would be even better would be to use the repository model used by linux distros for software distribution.
The user should be able to choose which sources of extensions they trust.
I use Vivaldi with NextDNS and LuLu blocking a layer up so between the 3 I get great blocking and love Vivaldi.
Vivaldi, uBO, Pihole. I feel pretty safe online.