Manifest V3, webRequest, and ad blockers
vivaldi.com
vivaldi.com
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.
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.
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.
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.
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.
Even easier if there's a shared open source fork. My company did it with 2 people
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.
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
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 already did that. Edge uses Microsoft’s fork of Chromium.
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.
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
> 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?
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 using Firefox specifically for a number of features chrome does not have.
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.
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...
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 currently use Brave, but if they switched to using Quantum I personally would just switch to Firefox proper.
This move is a blatant attack from Google on power-users, always in the name of "security" and performance.
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.
Replace Google with Mozilla, and you still have an accurate statement:
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.
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
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.
[0] https://github.com/gorhill/uBlock/tree/master/platform/mv3
Give it a shot and see that it still falls behind and doesn't block much of the annoyances.
https://github.com/raed667/uBlock-minus-mv3-cs-poc/releases/...
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.
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.
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.
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 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.
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.
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.
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...
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: [...]
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.
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,)
Is "don't be evil" still part of the Google's official ethos?
No it is not, and has not been for decades
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.
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.
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.
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.
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.
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.
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's sad that Firefox engine is so difficult to embed and we could have seen more projects using it.
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.
* 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.
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.
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.
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?
... That sounds like it's on Mozilla.
Its deprecated
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).
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.
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...
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.
Not on Android, it isn't. https://geckoview.dev
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.
Ads will win if MV3 is mass adopted and enforced. Time to set-up Pi-hole.
Vivaldi is great and all but they suck at privacy.
Source: https://privacytests.org
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...
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?
Next year is going to be the year of Firefox. Mozilla team intend to keep these APIs around.
Why? Why on earth would anyone want those built into their web browser?
Just because you might not be interested does not mean others aren't.
Mail and Calendar apps are mostly used from the browser now anwyay.
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.
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.
[1]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_La...
Why would anyone want a mail reader in their editor. /s
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.