 Chromium has long been the most popular browser, not only is it what powers Google Chrome by far the most widespread web browser, but also most others. You can use Edge, Brave, Opera, Vivaldi, Samsung browser and several others, you are still indeed using Chromium. Today, Chromium-based browsers make up most of the market share, but how has it become so popular? Like when Google released Google Chrome in 2008, everybody was using Firefox. It was Mozilla's open-source successor to Netscape, the browser that had not much long prior saved the web from the infamous monopoly of Microsoft Internet Explorer 6, thus gaining a lot of market share for bringing the long-awaited breath of fresh hair. At first, as one would expect, there was nothing majorly wrong with the browsers. It was based on open-source code, using modern high-performance components like the V8 JavaScript interpreter, and it quickly gained a lot of popularity, because it was fast. Just a few years after the release, there seemed to be no reason to use anything else. The browser worked very well, it has support for extensions, it worked swimmingly on smartphones, and it provided very handy sync capabilities that allowed users to freely switch between several devices without losing their open tabs, bookmarks or passwords. Firefox for Android had been around for a little longer, but it had never worked that well. Hence, a lot of people decided to trust Google in the name of convenience. After all, this was around 2012, and the ancientification of the Internet wasn't really a thing yet, and we still trusted Google to some extent. I, too, switched to Google back then. Chrome. It was just the logical choice, but as I was setting up my new browser with the same ad blocking and privacy extensions that I had on Firefox, I couldn't help but have a lingering thought in my mind. If Google makes money by profiling my data and serving me ads, then why do they allow me to just install ad block and use it? I remember mentioning this to my other techie friends, but they didn't seem to see anything off. Ad block users are a niche. There are so few of us that are using ad block that Google won't even bother. And at that time, it was true 10 years ago. 2014 is when things started to get ugly. Google took away the possibility to install extensions out of the Chrome Web Store, citing security concerns. And nobody really cared, though. Ad blockers were still available on the Chrome Web Store, so nobody's workflow was disrupted. In 2018, Google anticipated they were working on a Manifest version 3, a new security-focused API for extensions. It already faced a lot of criticism at the time, but as usual, people didn't really care. The deployment wasn't imminent, and ad blockers kept working. This was until, as of recently, Google finally decided to start moving to Manifest version 3 for real, after all. So what's Manifest version 3? So it is the newest platform that Chromium extensions will have to use. The name Manifest comes from the manifest.json file that must exist in the root directory of every browser extension, and contains information about how the extension is structured and how it behaves. This update is particularly interesting because it completely overrules the security model of browser extensions, implementing more default denial policies and a stronger permission system as well, to the point of limiting them enough to make it very hard for ad blockers to do effectively their job. In their documentation, Google claims Manifest version 3 aims to be the first step in our platform vision to improve the privacy, security and performance of extensions. Along with the platform changes, we are working to give users more understanding and control over what extensions are capable of. The changes will take several years to complete. But how exactly does this new platform work? Let's dive in. From permanent background pages to ephemeral service workers. Traditionally, browser extensions have always used a background page that ran on the same thread as the extensions and could be used to run arbitrarily scripts in the same thread. In order to ease the resource consumption caused by this solution, Google creates an object called the service worker. In practice, a Manifest version 3 extension will not load a background page that will stay alive for the entire lifetime of the browser session, but it will run a script called service worker.js on demand. This web page is not resident in memory. In fact, it gets started when the extension is needed and stopped when the script has been idling for over 30 seconds. First off, as an example, any listeners need to be registered immediately at the top of the script since they can no longer be a part of a promise or a callback. That is because since the scripts get started and stopped all the time, it is not guaranteed that they will be able to be registered otherwise. Secondly, it is no longer acceptable to store data in global variables. Global data now needs to be stored and accessed through the browser storage API, since the web page will get often destroyed and restarted. Later changes include the switch from timers to alarms for situations where waiting for a certain amount of time is needed. Is there any way to get around this limitation and prevent our service workers from getting closed automatically, disrupting our workflow? Well, the answer is sort of and this is exactly where the water gets muddy and political changes start to stack on top of technical changes. A script is not allowed to ask not to be killed for a limited amount of time. A script is allowed to ask to not be killed for a limited amount of time as long as that request is motivated by a long running operation that must not be interrupted, such as fetch requests and that is taken longer than expected. Since the web server is being slow in providing the requested resource or an intensive computation that blocks the execution for more than 30 seconds, here's the code snippet that can be used to achieve this. You can like, pause and write it. Where's the kicker? So, Google themselves said on their documentation that enterprise and education consumers where's the kicker? Well, Google themselves said on their documentation that enterprise and education consumers are allowed to access a special API to keep their worker active indefinitely, similarly to manifest version to extensions, but this feature will not be allowed in general. In fact, the documentation reads in rare cases, it is necessary to extend the lifetime indefinitely. We have identified enterprise and education as the biggest use cases, and we specifically allow this there, but we do not support this in general. In these exceptional circumstances, keeping a service worker alive can be achieved by periodically calling a trivial extension API. It is important to note that this recommendation only applies to extensions running on managed devices for enterprise or educational uses only. It is not allowed in other cases, and the Chrome extension team reserves the right to take action against those extensions in the future. Wow. If this wraps you the wrong way, you are very much not alone. This is not a technical requirement, it is a political change where Google reserves the right to decide who is allowed to poke holes at manifest version through restriction model in a completely arbitrary manner. There is another architectural change that comes with manifest version 3, the introduction of off-screen documents, and the move from single-threaded sequential operation to multi-threaded operation with message-passing and multiple child scripts running in parallel to each other, and to the service worker. So off-screen documents service workers do not have DOM access, but some extensions still need access to some sort of DOM to be useful. In manifest version 3, this is accomplished through an off-screen document and their companion off-screen API. In practice, the extensions will be able to ship with that special documents that are supposed to run off-screen, so not on the visible tab or window. They do not share this API with extension contexts, the only API they support is the Chrome.Runtime API, an event handler that is used for bidirectional message-passing between the service worker and the off-screen document. These documents can still be used as full pages that the extension can interact with, but they cannot be displayed to the user graphically. The off-screen API needs to be called from the service worker script, and it returns an object that refers to the off-screen document and has the same callable methods as Chrome.Runtime API. Chrome, again, here's the code. We've got technical documentation today. Remember how we talked about how the various documents and scripts that extensions need to have been moved off the main thread? This change does have benefits in performance, but it also means that they need to use message-passing APIs to communicate with the rest of the extension. JavaScript does not natively support multithreading, so it is necessary to resort to hacks like this in order to get multiple threads to work together with a colder execution stream. This API works exactly as you would expect. A common channel between the service worker and the document gets established first, then both the service worker and the document listen for messages from the other end and respond to them using that channel. This API can be used both for short, one-time messages. As an example, the document must notify the service worker that some kind of processed content is ready for rendering and should be rendered on the web page that is visible from the user and one for long-lived connections that allows for more messages to be sent for more complex use cases. Messages are JSON documents to serialize and deserialize. Message-passing is asynchronous and non-blocking, though, which makes this solution rather optimized. While in Manifest Version 2, the background page is started once and never re-initiated, in Manifest Version 3, the service worker gets caught only when it's needed. This means that any listeners that are registered inside of a promise or a callback are not guaranteed to work, they need to be moved to the top level of the script to work. Keeping a service worker alive indefinitely is only allowed in select use cases like enterprise and education applications. This is the part that is most worrying so far. Heavy limitations have been imposed on how extensions can work in the name of performance, but some parties can escape a great deal of what makes this change so painful for ad blockers and Google is the only arbiter of who can and cannot get around one of the biggest limitations of Manifest Version 3, especially since it has not been possible to install extensions from external sources for years. Also one of the most fundamental changes to the new extension interface is the new security model. In the name of security extensions now have to follow strict limits and have to run much of their code in a sandbox. One of the crucial changes that extensions face in Manifest Version 3 is that they are no longer allowed to download and execute arbitrary code from external sources, but all of the JavaScript code thing run needs to be bundled in the extension package, which needs to be distributed through the Chrome Web Store. This has advantages and disadvantages, though the course of history it has happened several times that browser extensions got hacked or both out and as they became compromised they began pushing and running malicious code in people's browsers without any sort of review. With this change Google will be able to review all code that users run, which allows Google to stop malicious code from being automatically downloaded to the user computers. Extensions that needed to deliver hot patches or just remotely download code for benign purposes can no longer do that and this can be a major limitation. Many libraries assume remotely hosted code and Google makes no exceptions for those, not even for its own first party Firebase library. There are a few exceptions to this rule. Firstly, you can still inject remotely hosted CSS style sheets into a web page using the insert.css method and secondly you can use the inspectwindow.eval method inside Chrome DevTools to allow executing JavaScript in the context of the inspected page. And lastly, extensions that act as debuggers are allowed to run JavaScript on a debug target. User script extensions like tampermonkey and violentmonkey will also get a pass for downloading remote user scripts. The change that impacts ad blockers the most is how modification of web requests work. Namely, the web request API was deprecated in favor of the web request API. What the fuck wrote this? No, seriously, it says Namely, the web request API was deprecated in favor of the web request API. Okay, look up. Okay, it's actually called the declarative net requests API. That's the new name. My script writer kind of, you know, messed up here. Okay, so back into track. But what does this mean for ad blockers and privacy extensions? So in manifest version two extensions could access the web request API. This API is used to observe and analyze traffic and intercept, block or modify requests in flight. This is an extremely powerful feature that allows to not only analyze traffic between the browser and the website, but it can also be used to block certain requests, interesting certain domains. In its API, Google uses a code example about blocking traffic to an evil.com domain, Chrome, that here's the sample. This by the way is what the architecture of an extension using the web request API looks like. While this approach is very powerful and it gives benign extensions a lot of flexibility, Google claims there are a couple of issues with it. It poses a security risk because it has often been abused by bad actors. There have been, as an example, instances of certain rogue extensions using this API to inject their own ads in web pages or inject malicious code that tracks users and snoops on their interaction with web pages. In the blog article where this change was imposed, Google claims that since January 2018, 42% of reported malicious extensions have used the web request API. Then there are performance issues with this approach. The main one comes from the blocking nature of this API. In fact, several of its events are blocking, meaning they pose execution of the color thread until they are done with whatever job they were working on. Each of these events can be bound to an unlimited number of event workers. Finally, no locking mechanism has been implemented to prevent web requests event to perform a blocking operation to a page that is already been blocked by another extension, which can cause execution to hang if not deadlock completely. In addition to that, using the web request API requires a persistent process to run for the duration of the entire session and it relies on several computationally expensive operations like serialization of the request data, the IPC messaging is required to send data from the API to the extensions and dealing with how the extension responds to receiving the data. The solution that Google proposes in this new version of web extension is to use the declarative net request API. To be completely honest, this new API absolutely solves the two outline issues. It can no longer be used to inject malicious code into web pages for one and its architecture is much more performance friendly, meaning that a poorly programmed extensions using this new API will not be able to completely halt your browser. The issue is that to achieve this, a lot of functionality was axed and this impacts even benign extensions that needed web requests to work. One of the affected extensions is Ublock your origin. Origin, yes. Ublock origin, the most reputable ad blocker available. When we consider a case like Ublock origin, neither the problems outlined by Google are a real issue. The extension is free and open source software developed completely in the open and subject to constant audits. Not only is it its use of the API pretty efficient and lightweight, but it oftentimes leads to lower overall resource usage since the overhead of using the web request API is far, far less than the overhead of running heavy tracking scripts and displaying the invasive apps that adds that a lot of modern web pages load. But why cannot you block origin just use the new API? Well, it's pretty simple. If you remember what we said earlier about the move to service workers, you will have realized that a common theme in manifest version 3 is switching from persistent processes to event driving approaches. It comes with no surprise that the declarative net request API follows the same philosophy as opposed to having the long running resident process of old and extension using the new API needs to register certain rules to instruct the browser on how to react to certain scenarios that are outlined in these rules. This shifts the processing duties of this web request from the web request API to the browser itself. Mostly we are going from the extension self being the central part of the web request handling process to the browser taking its role and receiving some guidelines from how to handle certain situations. This of course removes a lot of freedom from the extension as the extent of what the extension is allowed to ask the browser is very limited. Of course, on the flip side of the coin, is that an expression? Of course, on the flip side, this completely solves all the problems that Google saw with the previous approach. A malicious extensions will no longer be allowed to view any sensitive data as its handling is delegated to the browser. There is no more long running process to keep in memory and the cost of IPC and serialization is seriously cut down. Most privacy-focused extension developers such as Ublock Origin and Guthrie are expressing criticism on this new approach since it's simply not possible to block advertisement and arbitrary code to the extent that it was using the old web request API. The only vendor that seemed to be enthusiastically on board with a new change is Adblock Plus, an adblocking extension that has not been recommended for a long time since they have a financial relationship with Google and they allow a limited set of Google-controlled advertisements to slip through the cracks. Is this the end of adblocking? Well, if you use Chromium-based browsers, yes, kind of. However, not whole hope is completely lost. In an attempt to retain basic adblocking functionalities, even after the deprecation of the web request API, the Ublock Origin team has released Ublock Origin Lite, a re-implementation of the content blocker that is fully permissionless and Manifest Version 3 compliant. This new implementation of the extensions comes with what you would expect from what we just said. Non-persistent service worker, non-persistent web request processes, lower per-source usage. The key curve is that on top of not being as powerful and through as the regular Ublock Origin, it has to comply with a new default denial permission system. So you will have to grant the extension the permission to operate more advanced content blocking on a website, on a per-site basis. Click, click on each website. We can see upon installing the extension that there are three different filtering modes, basic, optimal, and complete. From the extension settings, a user can request to change the global parking. When this is done, the extension will ask for the user to deny or grant the new set of permissions it's asking for through Chromium Permission Manager. It is also possible to grant pair domain permissions if the global policy is left on basic. It is still possible to grant the required permission for optimal or complete blocking for a specific domain. While this is an easy process, it is also possible to grant a pair domain permissions or complete blocking for a specific domain. While this is a nice workaround, it absolutely cannot compete with a real deal and the flexibility that it grants. This cannot be considered a real solution. Enter Firefox. Fortunately, fortunately, Chromium is not the only browser vendor that discusses on the next steps for web extensions. Mozilla's Jekyll-based Firefox browser, in fact, will take a more measured approach. While it will ultimately have to migrate to Manifest Version 3 as well in order to retain support for modern extensions, Mozilla have said that they will not deprecate the web request API and that the implementation of Manifest Version 3 will different from Google in key areas in order to allow UBlock Origin and other private extensions to retain full functionality on Firefox. Moreover, Mozilla does not seem particularly keen on dropping Manifest Version 2 support anytime soon, which means that UBlock Origin and other privacy-focused extensions will just keep working on Firefox without changes for the foreseeable future. For those of you who left Firefox due to the bad experience with it, you are not. Using Firefox is actually a pretty good experience nowadays. It's a lot more lightweight than Chromium. Performance is absolutely good enough. Website incompabilities are rare and Linux support is top-notch, with Firefox having much better touchscreen and touchpad scroll physics on Linux compared to Chromium, as well as having more stable Wayland mode that is active by default, which also allows us to use smooth touchpad gestures that follow the finger from the beginning to the end, like buttery smooth one-to-one zoom and pan and two-finger scrolling to quickly go back and forth in your browser history. You can sometimes notice when there's like a sentence that gets cut in the teleprompter and I don't notice, go back and forth in your browser. On top of that, Firefox is extensively customizable. Allowing you to mostly work around any major quirks that you might have with it. There is an entire community dedicated to customizing Firefox through very pretty themes that give the entire UI a full makeover and for everything else, you can use a user.javascript user.javascript file, whether yours or one of the most popular ones. This allows you to customize every single tiny thing that you could possibly imagine, or tune Firefox to suit your specific needs. Let's also not forget that if ad blocking is important to you, even on Manifest version 2, the developer's claims that your block origin works better and more reliably on Firefox, and that you can use it in any way you want to. If you have any questions, feel free to post them in the comments below. Firefox claims that your block origin works better and more reliably on Firefox, and on top of that, it is also available on the Android version of Firefox, so you don't have to pick between having your password and tabs synced across devices or ad blocking on your phone, as you can have to do with Chrome. If you use Linux, it's likely that Firefox already comes pre-installed by your distro vendor, otherwise you can very easily install it from the repositories and be good to go. Migrating to it is not hard either, inside the settings you will find an import browser data option that can be used to seamlessly import most data from your old Chromium-based browser to the new Firefox, including the extensions that you have installed. This move might seem daunting, but moving over to Jakobrosers, as for the current state of affairs, looks like the only realistic choice that we have to get out of this very unfortunate situation. Thanks everybody for listening through this video, and as always, I will point out that the video is not sponsored by anybody. I don't get money from it, except, you know, advertisement, but you have ad blockers, which means I don't even get that chance. So, if you want me to, you know, keep on paying people to write scripts and, you know, write my own scripts as well, and, you know, record everything and, you know, pay the editor to edit this, editors say hi, all of these things, then I completely rely on donations, like 90% of my income YouTube-wise donation. So, I do have Patreon, I do have Ko-Fi, I do have LibraPay, I do have PayPal, like anything you can think of. And sometimes, like for this video, I actually publish the script of the video with images and everything first on Patreon, so you can just check it out as a preview, and days after on YouTube. So, you could have known about all of this Wednesday, I think, yes, Wednesday. I bet you're regretting it now. Yeah, yeah, sure. Subscribe.