Chrome Extensions and Ad Blockers VS Google with Oliver Dunk

Yeah. Thank you so much for having me. As you mentioned, I work on the Chrome DevRel team specifically on extensions.

I joined about a year and a half ago, so in January of last year.

Before that, I was an extension developer working at 1 Password, which is a password management extension. Oh, okay. Lots of experience working on extensions and actually going through some of this manifest version 3 transition myself and then solely been transitioning into this role at Google, helping other people migrate and trying to improve the platform to

really, really, that's, like, the Node extension. I think maybe the very 1st extension I install on any new Oh, nice. So nice. Yeah. Yeah. That's that's interesting stuff. We had talked we had Anna Publitz on, and we talked to her about, passkeys as well as a lot of the interesting stuff around with the one one password app and and how all that works. And I know that's probably a different show, but there 1 password does some really cool stuff,

specifically around, like, WASM and Rust and all kinds of neat stuff there. Yeah. I think it's a a really good demonstration of all all of the different things you can do with extensions, like you mentioned, WebAssembly to bring in other languages, hooking into different browser APIs to use different things like passkeys in different ways. Yeah. It's an it's a nice showcase of all of the different capabilities you have.

Big fan of that.

Talk about Sentry.

We are brought to you by Sentry, and, we would like you to try it out. So I'm gonna tell you a, a a bit of a funny story the other day is I sat down at my desk around 9 o'clock, and I I got a message from our editor, Sanity.

And he's like, hey. The I'm trying to grab the Open Graph image, and it's it's not running. Usually, I can just click this link and and download it. And I thought, oh, that's weird. So I took a look at it and go, oh, shoot. I had I had broken something when I had upgraded some some stuff in there, and I didn't think to check it.

So immediately, I I fixed it right away, went in, and I went into our century. And that was the only thing sitting in our century. We try to we try to keep our century nice and clean. There's there's no actual issues. If something's in there, we we convert it to a a GitHub issue, and then we go and fix the bug. But it was hilarious that the only one thing in there Sanity had Scott, the one bug on our entire website. Randy had caught us. I was like, that's a good The only bug. I was like, well, you need Sentry if you either need a Randy or you need you need Sentry.

And if you don't got a Randy, then you you're gonna need the Sentry to to find the bugs on your your site. So check it on out century.ioforward/syntax.

Awesome. Let's talk about the manifest v three stuff. Can you give us a quick rundown of, like, what does that even mean? So somebody listening right now, primarily web developers, may be interested in making a Chrome Chrome extension. What what's the big upgrade from like, first of all, what is the manifest? And second of all, what was the big jump from, what, 2 to 3?

Yes. I think quick is the tricky word there, but I'll I'll do my best. Oh, well, you get time. We we got an hour here. Goody. So Chrome extensions are very similar to other platforms that you may have built on. So Android, for example, has the target SDK Vercel, and extensions have the manifest version.

And that's the version of the platform. It dictates the different APIs that are available to you, some different behavior potentially.

And so previously, extensions were on manifest version 2, and now they're on manifest version 3.

And the reason we call it the manifest version is because every extension has a file at the top level of the project called manifest.json.

And that used to be set to 2, and now it's set to 3.

There were a couple of big changes there. I think the 2 most notable ones, Node was changing the way the background context works. So extensions are somewhat unique because they're running in your browser. But unlike a website where it's always open in a specific tab and so that tab is where your code runs, an extension may want to do something in the background, but it's not associated with any tab.

So previously, the way that worked is there was just a sort of invisible, what we called the background page.

We've now started transitioning to service workers. So if you've used service workers on the web, it's very similar.

It's essentially, a context that's running in the background that we can spin up when it has some work to do and then spin down when the work is complete.

So that was a a move that we made for performance among other reasons. But that does require some work from developers to migrate because the APIs that are available in service workers are slightly different to the ones that are available in just an average web page.

And then the other big change, as you mentioned, is, changing how some of the content filtering extensions work or more specifically, how extensions interact with network requests.

So previously, we had an API called web Wes, and there was a blocking variant.

And that allowed your extension to sort of be a proxy in between all network requests. So a request comes in. Your extension makes a decision for do I want to block this or redirect it, and then the request continues.

And there were some issues with that. So we moved towards having a new API, which we called declarative net request where you specify rules ahead of time. So you have a sort of JSON format where you can say, if a request matches these conditions, then please block it or redirect it.

And that has some benefits but also has some trade offs. And I think that's where a lot of the discussion has been.

Oh, okay. Okay. So previously, you'd be able to run some code at request time that will either say yes or no.

Yeah. And the new API is instead of being able to decide if you would like to do that, it's it's statically analyzable, meaning it's just a straight up JSON file. Is that right?

Yeah. Exactly. You're spot on. Okay. And

that these ad blockers in general, I know this this is big for for absolutely everything. Like, there's lots of really good use cases for this as well, but obviously, ad blockers is one of them. It's pretty wild, the the size of the lists for these types of thing. Like so we were having, an issue on the other day. What what was it? Plausible analytics? No. It wasn't even plausible. Like, that was that's a legit use case. We we did have a issue with plausible Wes, we don't want people to block it. So we're trying to, like, proxy it and and rename it. But I had a, like, a legitimate component on the page that was being blocked by some Safari extension. It Wes, like, it was thinking that the name of the component, because it had the word some random word in it, it was blocking it. So I went down the rabbit hole being like, what is it? What is in the specific component's name that is is blocking it? And I downloaded the list of possible blocks, and it's 1,000 and 1,000 and 1,000. And, like, I understood that ad blockers were, like, just lists of things to actual block and selectors and and JavaScript files. But I didn't realize that it was such a cat and mouse game of literally thousands and thousands of regexes that are in there. So I don't know. That's not necessarily a question for you. I just was thought I I had mentioned to the audience of how wild the the world of ad blocking is.

Yeah. Some of those lists are are really big, and I think that was one of the things that came up a lot that in our 1st version of manifest Wes free, the limits were quite restrictive. And so representing all of the rules that you might want a user to have could be quite hard.

And there's a few reasons why there were limits at all. So, performance is 1. I mean, the the more rules you have, of course, the longer it takes to evaluate those. Yeah. Also from a review perspective, there are ways that you can abuse rules. So we want to make sure we're checking over the rules. But the more rules you have, the the harder it is to look over them.

And, also, like, we don't want the list to grow unbounded, so we want some sort of incentive to make sure that the list is kept pruned.

Yes. But as I mentioned, like, there's a trade off between we want the limit to be reasonable, but we want it to be reasonable for everybody. So we want to make sure our blockers have a high enough limit as well. And, actually, that community has been really good at when we've asked sharing data.

And I think we're in a place now where we've increased the limits quite significantly.

And, hopefully, for the vast majority of users, the number of rules that are needed to take the functionality they had in manifest v 2 and migrate it, that that number should be below the limits that we have.

Okay. Okay. And, like, how do you know what that is? Like, how many possible things can you you add in there?

Yeah. So it's it's complicated. It gets a little bit nuanced. I think the the easiest number that's true in most cases is 330,000 rules.

So that that's broken down a little bit. We have a global limit that says across all of your extensions, you can use up to 300,000 rules.

But then we don't want one extension to be greedy and use all of those rules. So we also say, irrespective of that limit, any specific extension has 30,000 of its own rules as its own separate limit.

So the best case scenario, which is probably the likely scenario for most users, is they have one extension that's making really heavy use of this API, and it's using all 300,000 of those global rules and its own 30,000 rule limit as well.

Okay. Okay. That makes sense. And are those rules like like, what does a rule look like? Is it a is it a regex? Can they be partially matched?

Yeah. So there's there's different conditions you can have. You can have regular expressions.

So for example, a filter on the URL or the query parameters, there's it's quite a complicated syntax that we've been building out over time as we've had requests for for different things.

And something else that I didn't mention is there's, different rule sets types that you can have. So, what I was just discussing there was static rule sets, which is what we expect the vast majority of rules to be. And that means when somebody uploads their content filtering extension to the Chrome Web Store, they bundle in all of the rules at that point. But there are also use cases where you need rules that only apply for, like, this specific session or, like, that are just dynamically changed from what you submitted to the store. So there are also additional limits where you can

Yeah. The the simple answer is no. And I I realized for some people, that may take more convincing than others. But it has been really nice the whole time I've been at Google. I haven't seen anything to suggest that that's the case. And, actually, lots of things to the opposite. Like, it's a community that we work really closely with. We had a WebExtensions community group meetup in San Diego a couple of weeks ago, and I was there with Andre from AdGuard, and he was in attendance. So we had lots of great chats.

We attended and sponsored the ad filtering developer summit, which is a summit that happens to talk with all of these extension developers. So, yeah, we we really are trying to work with them.

It's tricky because we have constraints on our side as well. So Mhmm. We can't always give everyone everything they want, but it it really is like, they're some of the most popular extensions that are available, and Yeah. We do want to support them.

So the reason for getting rid of the blocking variant of the web request API is is sort of twofold.

1 is the performance angle. So if if you look at sort of the whole history of Chrome, performance has always been a big selling point and something that's really important to everyone.

And another thing to know about Chrome is it has a multiprocess architecture.

So the way the web request blocking API had to work was you have the extension that's running in 1 process and then the browser that's making all of these network requests ESLint another process.

And every time a request happens, it has to send that request across to the process that the extension's running in. And the extension has to make a decision, and then it has to send a response back.

And for 1 request, that is pretty insignificant.

Yeah. Of course, we do it as quickly as we can. But as you start making more and more requests, that starts to add up and that starts to be slower.

So that was one reason that changing approaches made sense. And then the other is just privacy and security like you mentioned.

Extensions were basically acting as like a network proxy that had access to all of your requests. And, like, for the the good guys, the the extensions that most of us will use, that makes sense. But we also saw a really significant amount of abuse where extensions were requesting access to the network Wes on all of your sites and then acting as a proxy and doing something more nefarious. So Mhmm. There there were sort of these 2 pointers that maybe this is an API that's worked up to this point, but it's something we need to start reconsidering.

Yeah. You I I I'm I don't know how much you're allowed to talk about that, but I always love to hear the stories of, like like, what are the bad guys doing? Because that that I'm sure that's a huge part of it as well of, like like, even that, like, Honey Chrome extension that I'm I don't I don't specifically Node. But, like, I see my friends who are not technical being like, install the Honey extension, and you just Wes all TikToks. Yeah. Yeah. And it's just extensions doing something. Yeah. So it's totally free, and it's just gonna try it's gonna save you all kinds of money. Like, somebody's paying there, and they're probably, like, harvesting your data. And even yesterday, I saw this, an old email from Mark Zuckerberg being like, hey. We can no longer track what people are doing on Snapchat.

Mhmm. Fix that. Yeah.

So are you Yeah. Can you tell us, like, what are some of the nefarious things people are doing with rogue Chrome extensions?

Wes. So I don't have any specific examples to to mind.

I think cookie theft is is one example that, is sort of a problem across the web, and the extensions have been part of that in the past.

There are also, like, some great write ups if you go looking for them. Mhmm. There's a a really great security community around Chrome and extensions as well that, are looking into these things. So you Node definitely find that.

Yeah. The the cookie theft is you had another one. If if somebody can access your cookies via JavaScript and just send those over, can can a Chrome extension access non JavaScript? What's the what's the word? HTTP only. HTTP only cookies? I yeah. It should be able to. So it through through the web request API, it has access to the headers. Oh, yeah. You're right. So it can read then. Yeah. Yeah. It can read anything. It's like a it's a a very privileged spot to to put a Chrome extension in, which is why I'm always, like, a little bit nervous to install 1 because this is like, yeah, it's it's built by some dev out there, but like, all that you need is some company to come along and buy it. You see a lot of people buying chrome extensions, you know, and you Scott to think, oh, what are they what are they doing with that? So, like, maybe another question about the the security side of things JS, like, so somebody submits a Chrome extension to the Chrome Web Store, and Chrome is reviewing all of those ones? Is there someone looking through 330,000 lists of block rules to figure out nothing's going wrong?

Yeah. So that that's sort of a a huge topic. There's there's a whole team that deals with review on the Chrome Web Store and and making sure that extensions are safe.

There's a combination of, like, automated review and manual review. So some things can be caught just by, sort of tooling that can look through the code and spot things that look amiss. Other times, it is somebody actually sitting there and and reading through the code and trying to understand what's going on.

And then, of course, there are various signals that we can get once an extension is released to make sure that it continues acting in the right way. And if something is published and then we spot that something's amiss, we can also take action then. So there's there's lots of different stages where things happen, and it's a very nuanced process that, like, con consumes a whole team's day to day, and I'm sure they'll they'll always have work.

And you can't necessarily talk about those either. Like, we we had, for us on from socket dot dev, which does something similar for NPM. It scans every single NPM package in existence, and it has a whole bunch of signals to say somebody's trying to do something funky here, and then raises up a right red flag and and sends it over to a human. So if you make those things open source, then you're also telling the bad guys what you're looking for. Right? It's probably tricky.

Yeah. No. There's there's a hard balance. Definitely, I I think one of the things that developers say a lot is that they they feel like they sort of don't feel like they have too close of a communication channel with that review team, and that's something that we're trying to to make better.

But but it is tricky just because, like you say, you you have to be careful with what you share. And pnpm every good person that has a genuine question about why something was turned away in review, there's also somebody nefarious that's trying to ask the same question and learn information from it. So it's a really tricky one. Oh, I see.

Man. And another piece of criticism that I I hear is, okay, well, there's a review process. I have to give you a list of whatever. And if it takes a week to get my my update approved, then that's a whole week where I'm without specific blocking of it. So because the way that it works now is it's going to go off to some server and every however however often it needs to, it can redownload the list of new blockers because Yeah. Like, YouTube rolls out a new fix to the ad block, then the ad block blocker, it rolls out the fix to that. And then YouTube's ad block blocker blocker blocker rolls out something new, you Node, and it's a it's a constant back and forth. And there's not any, like, there's no moral discussion here of whether you should be doing that or not. But people are saying, I want to be able to have to sidestep Google's review process and and have open lists. So is there any way to do that?

Yeah. So there's the dynamic rule sets that I I mentioned previously. So extensions do actually have an API where there are some slightly reduced limits, but they can dynamically add rules that weren't there when they initially submitted the extension.

And, like, we've looked at the data to try and make sure those limits have enough allowance that in the time we expect extensions to go without being updated, they can continue to update the rules that way.

Okay. We've also been working on allowing extension changes that only change declarative net request rules to fully bypass the Web Store review.

So that should be a nice way to even if extensions still do have to go through the Chrome Wes Store, skip that whole review aspect and allow them to get an update out. Oh, yeah. Hopefully, within within minutes.

Google's listening and, like, working too. We're we're really trying. The good turns. Yeah. It has been, like, I I would say, like, maybe half, if not more, of the the work that I've done over the last couple of years. So it's something that I'm, like, thinking about day in, day out, and I'm really trying to do the right thing.

Yeah. I mean, we we definitely see it all.

There's there's various places like you mentioned, YouTube comments. We have a developer mailing list, which is really great.

And, actually, there's a really nice community there. Like, we get some really genuinely good feedback, and we've we've made changes based on that. Sometimes people point out a bug or point out an issue.

And, yeah, obviously, all the other places as well, Twitter, Hacker News.

Mhmm. I I try and monitor all of those. I was, you know, part of those discussions before I joined Google, and now I want to make sure, like, that they're not forgotten and they do get passed along. Yeah.

Another big use case of Chrome extensions is and I I personally write in quite a bit these myself whether it's for, Arcboost or, Grease Monkey JS I do want to run code on the page or I want to be able to modify the dom in some way. So moving the code out of the the background page or or from the DOM into a service worker where there there is no concept of the DOM, how does that work with with this new v three?

So it depends exactly what you're doing. If you do, like, specifically want to modify the page, then the way you do that in extensions is called content scripts. And so they're TypeScript that get injected into the page and run.

And they're very much unchanged. Like, you can still have content scripts in manifest version 3. You can still access the the full DOM of the page.

If you're doing something that you do actually want to be in the service worker and in the background behind the scenes that you need access to the DOM, at the moment, we have something called off screen documents.

And that's basically an API that allows you to open a DOM based context that you can run some code in, and then you can close it when you're done. And so then you still have sort of this escape hatch for if you need access to those APIs. Long term, that doesn't feel like a great solution, so it's definitely intended as like a temporary stopgap.

Yeah. The hope is to try and make as many APIs as possible work in service workers.

So, like, we've made some changes to how web push works.

We've recently launched a port for Wes USB, web HID, web GPU, and service workers.

There's, like, a whole list of APIs that we've already made work in service workers, and we're we're trying to do that more. Nice. Awesome. I I'm always curious about that if we will start to see

a lot of the DOM APIs move to the service worker because like I use a package called Linked DOM or Linked DOM and and it it essentially does that JS it it recreates the entire document so you can do things like Vercel selector and inner HTML, and then you can sort of play around with it. And JS yeah. Canvas off screen canvas is available in because that's a huge thing JS drawing to a canvas is really laggy on the, if you're doing some really complex stuff. So wouldn't it be nice to throw that into a service worker? And I just checked it. It looks like it's there. So do you think we'll we'll see more DOM APIs and service workers?

Yeah. I think this is an interesting one where, like, we're the extensions team, but extensions are built on top of the web. So Yeah. There's also, like, a whole team responsible for service workers.

Like, we need to work with them.

In the conversations I've had, the the the conversation has always been, like, they're generally very supportive of bringing new APIs to service workers.

Previously, service workers were very much related to web pages and handling network requests.

So in that context, there just wasn't a really strong justification to bring APIs to service workers.

But now we have extensions moving to service workers and other use cases for service workers.

I think there's a a general shift towards let's make more things work.

Mhmm. And so that's like a conversation that needs to keep happening. And, like, clipboard, like you say, is a a really compelling case that I think we need to talk more about. But, yeah, I'm I'm super excited. I hope we get more APIs.

Me too. Even just, like, the server being able to do it on the server, like, wouldn't it be cool if you could do a canvas on the server, or wouldn't it be cool if you could create a whole dom on the server? And, of course, we can do it with extensions and whatnot, but I would love if those APIs just worked absolutely everywhere. And we seem to be trending in that way, that direction.

So you're thinking, like, Node. JS as well?

I I think so. Like, Node is Node is really starting like, they added add event listener. Right? Yeah. They've been they've been adding a lot of the, like, browser APIs.

I think partially because they see Deno and Bun, implementing them as standards, and and also, it's just it's nice to not have to do, oh, event event emitters in in Node and custom event in JavaScript. No. It's just custom event across the board. It's all web standards.

Yeah. Yeah. I don't know the context, but I saw on Twitter over the weekend or x, I should say, somebody prototyping with, like, local storage and session storage being available in Node. Js.

And that seems super exciting.

Yeah. Yeah. That. And, and Node was was kinda first with the, the async local storage API, which there's now a browser standard version of that.

So, yeah, like, all of those things

Yeah. This is I've been asked this question before, and it's always an interesting one. I think the the Node extension that I used to be really excited about and give us my answer to this, it was actually a Google extension. So not not something I worked on, but, maybe, like, it would be nice to have something from the community.

But there was a picture in picture extension Wes, before picture in picture was widely available, there was an extension that would allow you to take a YouTube video or take some other media and have it in picture in picture, and that was really cool.

The other one that jumps to mind is one that I built.

And it basically, I have a spotlight that, like, I use for meetings just to make sure I'm well lit.

And I have an extension that looks to see when I join Google Meet, and when I do, turns the light on. And it's, like, super simple. It's just like watching for the tab title to change and then doing a fetch request to the API.

But it just makes me smile every time I join a meeting and I see the light come on, and I'm like, I built that. That's the thing that I use.

Yep. And then occasionally, you'd have a tab that matches the condition for some other reason. And so you're, like, you're reading an email that happens to have him eaten the subject, and your light comes on. Yeah. Oh, that's hilarious.

I I had done that with this app we're using right now, Riverside, where I have to push the button to let Scott in.

And we like that for the guests because the guest doesn't come in before we're ready for them, but I don't like it for Scott. So I wrote a it's not a Chrome extension. It was just a a Grease Monkey script called Let Scott in. And it just every, I don't know, every 5 seconds or so, it checks if there's a button that says, besides Scott name. And then if it is, I I send a click event to it, and it lets him in.

I that's why I love the web so much JS being able to to tweak it and make it exactly how how you want it because Yeah. You can have full control over the websites. Not full control, but if something bugs you about a website, you can make those things that you want. And maybe that's, like, the follow-up question I have for you is, like, have you guys ever thought about doing something for Chrome extensions similar to Greasemonkey or Stylish or something like that or Yarn Bos Wes it's like, I just just wanna run, like, a little bit of code on this website JavaScript.

Yeah. Instead of like, I don't wanna do the whole here I am taking a Chrome Chrome extension tutorial and and manifest and the live reload and and whatnot. Have you ever thought about doing something like that?

Yeah. As far as I know, it's a path that's never been, like, super seriously gone Node, but it's definitely, like, a discussion we've had.

Some of the things that are happening, like Bos, like you mentioned Mhmm. I think are really interesting. Like, it's a very different paradigm compared to what we're used to.

We're in a place now where, like, most of the major browsers are implementing the same extension API, which is really exciting.

But it does mean that we've kind of all converged on what we think this should look like. Mhmm. And, like, maybe we don't have as sort of, big new ideas, that are, like, as radical.

And so I I find things like that super interesting.

It is interesting. Like, you mentioned Greasemonkey and, like, said sort of we're not talking about extensions, but, like, that is an extension behind the scenes. Yeah. And end user scripts is another big part of the manifest v free transition.

So Wes have a new user scripts API, which is available now.

And that is, again, to do with addressing a limitation that there was in manifest version 3 and trying to provide a new API for it. So Oh. One of the changes we made was that extensions couldn't load remotely hosted content.

So or so there's a little bit of nuance there. You can load sort of config and that sort of thing. That's fine.

Or, like, data from an API.

But we don't want you evaluating code that you get from a remote source because that's open to a lot of abuse. Maybe the code that you're evaluating changes after we've reviewed the extension.

Yeah. Maybe it gets sold and then linked somewhere else. Yeah. In in many ways, that's exactly how TypeScript scripts managers work. Like, some code is provided that wasn't there when the extension was reviewed, and then you want to be able to run it. So we added another new API, the user scripts API.

And that explicitly gives you the permission to do that in a in a certain way.

Oh, okay. Yeah. Because I'm I'm thinking about, let's say I have, like, a CRM, and I wanna be able to have an ex a Chrome extension for my CRM in my email. You know? I'm I'm I'm viewing my email or or my courses, and I wanna say, alright. I'm looking at an email from somebody. I wanna load in what their purchases in the sidebar because then I get a bit of context for for who they are.

Is that type of thing doable, and and which APIs would you use to do that type of thing?

Yeah. So you I'm just thinking through the the use case you you went through again. So it's like, you're looking at your CRM, and you want to do anything

Or if I'm let's say I'm in my my email ESLint. I'm on Gmail Scott, and I wanna write a Chrome extension that puts a a sidebar so that when I'm viewing an email from somebody, it it goes off to my CRM's API, pulls all their purchases, and puts them into, like, the sidebar of the Gmail so that I have a bit more context for who that person is that I'm emailing.

Yeah. So you can definitely do that. Like, that's a case of fetching remote data, so that's completely fine. Mhmm. You need a content script because you want some amount of access to the DOM. Yeah. And then previously, you would have used that content script as well to inject some UI. So you would have as if you were a developer on the page, like, document Scott create element div, and then filled that div with all of your content, and then added that somewhere to the DOM.

Actually, last year, we launched the side panel API, which is the API designed specifically for this use case. So that allows you to specify a page within your extension bundle that gets loaded as a side panel.

And so I don't know if you're familiar with the side panel in Chrome. There's like a little icon in the top right. But you can open that and you can have extensions display there. So that's quite a nice way of having an actual separate bit of UI where you can render some content and Mhmm. It's not impacted. Like, if the layout of Gmail changes, you don't have to worry about, is my extension gonna inject in the right place? Is it gonna be styled correctly? Oh, that's nice. No. I I was not aware

of that. Oh, that's really nice. Big fan of that.

Cool.

Let's talk about the the actual development stack.

Like, what does that look like for somebody who wants to use TypeScript and have the thing live reload and maybe they wanna bundle their code? What what does the stack look like for or the tooling around building our Chrome extension these days? It's been probably a couple of years since I've done one myself, except Wes, like, the Twitter blue came out.

I I made a Chrome extension called Who Blue, and it would it would show you who's paying for Twitter Blue.

That was just kind of a fun little code along that we did, but I never did submit it. Yeah. So the really nice thing is that the basics are super simple.

Like, extensions are HTML, CSS, and JavaScript.

So if you've made a website, hopefully, you're familiar with those, and moving into an extension should be really easy. Then you can start to build on top of that. So, yeah, again, it's very similar to web development.

You you start off. You're just writing those files by hand. You're not doing any sort of minification or or anything like that. But then you want to start including libraries or using Sass or all these different things. And so then you can bring in some sort of bundling tool.

And so all of those tools can be used with extensions as well.

When you get into TypeScript, there are types libraries that can give you all of the typings for the different extension APIs.

And so you can sort of slowly build up. There is some tooling available that does a lot of this out of the box for you. So CRXJS is one of them.

And that's a a plug in that basically tries to add all of the things that you might want. So the hot reloading, like you say, where when you change a file, it will automatically reload your extension.

Oh, this is a v a v plug in.

Yeah. There's v, and I think it does have support for at least 1 of her bundler as well from memory.

Yeah. Yeah. It has roll up. That's cool.

Yeah. Oh, that that was good. Because that that was my biggest pain point JS you had to go to the weird button in Chrome and and press reload and and whatnot. Obviously, that's

much smoother now. I'm still doing that. I I didn't know. I I've seen some really clever workarounds for that as well.

So, like, one Node that I quite like is you can have, at the very end of your build process, just opening a URL, and you can just pick, like, a a a URL that you know isn't actually gonna be used, like, reload my extensions, and then you can have an extension which is listening for that URL to be opened in a tab and reloads itself when it sees that.

Oh, an extension can reload the other extensions,

or it can reload itself? Right now, you can only reload your own extension, but we have definitely had discussions around adding an API to be able to reload other extensions for this specific reason.

Oh, wow. I got a a question. And you might be the only person on Earth that can answer this for me given that you worked at 1 password and, work on Chrome extensions.

So I use Firefox and Chrome. And Wes you want to autofill 1 password on on Firefox, you just push the little Node password Scott, and it it'll it'll prompt you to put in your password or or face ID or whatever.

And on Chrome, it says go to the URL bar and click it. And I said, no, I'm not I'm not going to reach for my mouse.

Yeah.

Why is that? There's gotta be some limitation there.

Yeah. So there's there's 2 pieces. And, actually, this is nice because I think it draws on both my Node password knowledge and my Google knowledge. Exactly. Yeah.

So the the the first piece is that, Node password's extension has the ability to connect to the desktop app. And Yep. Based on whether or not you're connected to the desktop app, it can have different behavior. So it sounds like that probably isn't the case in your situation, but that can be the case if, for example, Chrome could connect, but Firefox couldn't for some reason. The other piece is that there is an API action Scott open pop up, which all browsers have generally agreed on. But it's shipping in Firefox and it isn't shipping in Chrome.

So that API would allow a developer to say, at this point, I'd like you to open the pop up, and so then you can avoid having that click.

I'm really hoping we can get it shipped soon. It was something that actually, when I was at 1 Password, for this very reason, I I really wanted, there was a bug that was, blocking shipping that API in Chrome. That bug has now been fixed.

We we need to do some final checks just to make sure we're happy with the rest of the way the API is working and there isn't anything we've missed.

But that is really one that I want to ship. And, yeah, I I know the 1Password team has really wanted that Node. So I assume if we ship it, they'll be straight on to to using it. Oh, awesome. That's that's good. I often wondered about that because I thought in my head it was

there is an inherent trust in anything that is outside of the web page. So the URL bar and up in Chrome is I trust that.

And if somebody puts a button in the browser, anybody can put a browser that looks like the 1 password button. And if it if it tries to, like, mimic a pop up and tries to actually get your password, then, like, you know, that's the same thing with, the notifications API in Chrome as well. There's a reason why it slightly overlaps the URL Bos, and that's something that I look for every single time that one of these things pop up. So that's kinda why I thought it was.

Yeah. The line of death concept, I think it's called. Is that what it's called? Okay. I think so. Wow. I I could be wrong, but I'm pretty sure.

Yeah. So, I mean, extensions work pretty well with dev tools. So, like I I like I said, they are based on the same technology as web pages.

So, just in the same way, you can debug a web page.

You can open dev tools. And in there, you can there's actually on the console tab just below, there's a drop down where you can select the context that you're looking at. And so, by default, that's just like the top level page. But if you have any content scripts injected by extensions, you'll see those as well.

And similarly, in the sources tab, you can switch to content scripts and look at the individual scripts.

And then also on the chrome colon / extensions page, which is where you manage extensions, there's a developer mode toggle.

And once you enable that, you see a lot more debug information.

You can inspect the various context for extensions, and that opens, like, a special dev tools instance that's for the background page or for the service worker for your extension.

Nice. Cool. I actually did a video on this. So if anyone is interested Oh, really? I don't know what you'd have to Google to find it, but sort of how to debug extensions.

It's on the Google for developers channel.

Cool. It's, ESLint on our team has a series called Dev Tools Tips. And as part of that, we did a video together where we talked about various ways to debug extensions.

Alright. Found it. I got it. Oh, Scott, I found it too. It's always the race for Scott and I. Before you did. For the show not yet. Yeah.

Oh, that's great.

Cool. JS there anything we hadn't touched upon with the Chrome extensions

or anything before we hit the other session? Summary. We've spoken about it a lot.

One thing that I did hear so I I listened to both of the episodes where you spoke about manifest version 3.

And I think in the second one, something that came up Wes, if we're getting rid of the web request blocking API for all of these reasons, why can we still have access to the web request API? Which I think is a really good Wes, and it's a a fair point that's been brought up. The reason we wanted to get rid of the blocking version was for all of the reasons I mentioned.

Mhmm. Some of those concerns apply to the general web request API. Some of them don't.

But the the blocking version felt like the really easy one where we can see some very clear ways to provide a better API for these use cases.

And so trying to move those developers to declarative net Wes was a good way to remove a big chunk of the web request usage.

And now the remaining usage, we can look at a lot more closely, and it's hopefully at least less common to use that API.

For the remaining usage oh, go ahead. No. No. Go ahead, please. I was gonna say, for for the remaining usage, we are making other changes to, like, address the fact that it is still available. So, for example, red redesigning some of the permissions venues to make it clearer.

What site does this extension have access to and and our user to limit that if they want to?

Cool. So that you'd still do have access to the web request API. It's just not blocking, which means you can't stop something from from going through there. I'm always curious about that because, like, you can like, let's say there's a a ping out to an external server for with some tracking information in it, and it didn't get caught because, like, Scott, like, we try and do on syntax website is we rename the endpoint so it doesn't hit any of the doesn't hit any of the the blocking one. Like, we renamed it to, like, elephant or something silly like that, Or you intentionally name it something that is a known good API, which I'm sure lots of people do it as well. But I always thought, like, okay. But, like, Node step further would be, like, looking at the payload that gets sent over. Right? Because at at some point, the payload needs to match. And I often wonder if you could just, like, somehow fingerprint that payload to say or or even have, like, a vector search of known payload tracking payloads and say how is this a 98% close match to this vector database of of all of the the tracking? And if so, then then block it. Is that ever something that would be considered?

Yeah. It's a really interesting question.

So right now, you don't have access to the body into targeted net request.

Okay. I think I have heard of some developers who have done some really interesting things with using the observational capabilities in the web request API.

And then once they start to get some signs that maybe this is a request we should block, they then create a declarative net request rule to block it. But definitely expanding the API is something that we're open to.

One of the things that we're really aware of is that, like, now more of the API is declarative and you have to like, we have to expose capabilities for you to be able to do certain things. Mhmm. That does mean that we are also much more part of the story of how new capabilities get added to content filtering extensions.

So we're we're trying to bear that in mind. And if we hear from lots of developers, like, this specific condition or this specific thing that we want to look at at a network request isn't available, then we want to have the resources available to look at that.

I hope so. And I I think we're starting to see that.

So we're we're getting close to the m v two deprecation now. That starts in June, hopefully.

And already, like, there have been blog posts and development builds that different content filtering extensions have released that sort of prove that doing things in manifest version 3 is possible.

And like I mentioned, we work with them very closely. So I think, generally, the sentiment is changing a little bit and Mhmm.

Understand the reasons for the move and are starting to figure out that, actually, it's it's not quite as bad as it seemed.

Nice.

That's good.

Do you run an ad blocker yourself?

I don't. Node? Okay. I do. I do. I have an ad blocker in a profile. So, most of the time, I find I can generally like, on the websites I go to, I can put up with the ads that are there. Yeah. Sometimes on certain types of sites, it gets a little bit infuriating.

But, yeah, I have a profile where if I want to access a site that is is particularly covered in ads or, like, JS it is getting in my way, then I can switch to that profile.

Oh, yeah. Yeah. You just or I even wonder if they could have, like, an opt in instead of an opt out. Because I often have to go to websites and and turn it off just because it's it's breaking something. Or or even on my own course player, for some reason, people that use privacy badger, it will randomly block Vimeo requests or video ESLint because of the way they use cookies or something. So I had to write a whole bunch of code that at the time, Vimeo didn't have a way to catch those errors, so there was just no way. So I had to write some code that would, like, test if I something was blocked. And then if that was the case, I put a big banner up and say, hey. If you're having issues, this is why, and you have to allow, privacy Badger on this specific site or at least for this specific domain name so I can do my embed. So it's it's a constant cat and mouse game with these types of things, and you're often breaking

good things as well. Yeah. I think this is another example of the sort of thing that comes up time and time again, which is because there are people that are doing the wrong thing, it affects the people that are doing the right thing. And the goal is always just can we try and make that happen as little as possible?

We live in a broken world, Oliver.

Oh, I feel like this is a depressing note to end on.

Oh, no. Well, let's let's talk about some exciting stuff.

What, laptop and keyboard do you use?

I have a MacBook Pro, and then I just have the Magic Keyboard, which I know is a really unexciting keyboard. And I should probably get some fancier mechanical gaming keyboard. But Yeah. Yeah. It's it's just I see you have 1 as well.

I've got, like, like, 7 mechanical keyboards, and I just can't do it.

Just just keep going back to the normie, one. And what about a code editor? What are you using?

Usually, just BS code.

I I really like that. If I'm doing Java, which I don't do much anymore, but occasionally, IntelliJ.

On, like, coding in general?

Trying to read. Like, I I find, like, Hacker News, if for all of its flaws JS a is a great place to just get a general feel for what's going on and, like, what the interesting things Yarn, and then just trying to build things occasionally. It's not always easy to find time, but Yeah. Like, building little extensions like that one I mentioned is a a good chance to have an opportunity to play.

Let's move into the last section here we have is Sick Picks and Shameless Plugs. Did you come prepared with either of those? Mhmm. I did. Yes. What do you got for us? So Sick Picks,

there's so much I could talk about. We could just do a whole episode where I just go through things that I love it. I feel are underrated, and I want more people to know about. Give us as many as you can then. Yeah. We'll we'll take them. I I I think the the one that I had in mind, was the Defunctland YouTube channel. I don't know if 5 of you have come across that. I love it. Defunctland.

Okay.

Yeah. So they do, like, documentaries on, often, Disney or just generally, like, pop culture and entertainment.

But they're, like, really high quality documentaries.

If you haven't seen any, I'd suggest their Disney Fastpass Node JS worth starting with, or maybe they have 1 on, like, the origins of the Disney Channel theme.

But they're just, like, so well produced. You you think, I'll put this on, and I'll maybe watch 10 minutes of it. And then you find yourself glued to a chair. And I just have so much respect for, like, it's a a new format making online videos, but, they they really managed to to to make content that feels like it could be on TV or on Netflix or on one of the big streaming services.

It's like a an amusement park ride that it's like an old Garfield one that's totally broken down. I think I remember seeing that with all of the, like, sort of neon paint that shines in the the light. It it's just bizarre. The whole thing is weird.

Oh, I I had sick pick the Action Park documentary a while ago, or may maybe I watched a full blown action park documentary, and then I went to YouTube to I wanted to more about Action Park, which is this, like, horrible theme park that, like, all these people died at because it was super unsafe.

And they have a really good one as well. Oh, I Sanity. Gonna watch more of these.

Oh, sick pic. Do you have any any more?

That's the main one that jumps to mind. And then, like, Lemono is another example of of that sort of a very different subject matter, but also, like, very high quality documentaries that, just always blow me away. What what is that? Lemmino? Lemmino. It's l e m m I n o.

Yeah. If you if you just sort of have some time, you could easily, like, kill a weekend just watching those videos.

And he makes all his own music as well, which is even more impressive. Like, I

Yeah. I think, first of all, just go build an extension.

As we mentioned, it's it's super easy. It's technologies that you may already know if you're listening to this podcast. So, just search like, the getting started guides. You should be able to find them pretty easily.

And, yeah, give it a try. It's fun to build something.

So the the Node on the, like, Chrome for developers site is is really good.

And there are some tutorials there, and they really try and take you through the basics of, like, what is the fewest number of files you can create to make something that will load in your browser.

And then something that I built, the web extension playground, if you Google that, you should be able to find it.

And that's like if you've used the TypeScript playground before, it's the same idea. It's just somewhere where you can build an extension.

It has all of the typings already loaded, so it hopefully Oh, cool. Removes a lot of the Node setup and choice and just just makes it a little easier.

Oh, that's cool.

Yep.

Is hold on. Is Safari adopting the v three manifest as well?

Yes. So Safari has support for manifest version 3.

They have support for both service workers and limited event pages, which is something that Firefox has.

But, yeah, Safari are full on the the Webexxion APIs.

They have support for manifest version 3. They're they're full steam ahead. It's it's super exciting.

Wow. Oh, man. For some reason, I always thought Safari did their own thing with extension, which is why you never had very many good Overlap. Extensions on Safari. Previously

have some some different options. So they had Yeah. Extensions rather than web extensions.

But they're they're slowly moving, and, like, they're part of the community group that we have.

Wow.

And do you know I know you're you're not from Apple, but do you know if that's

on mobile as well? Because they have it in the mobile. On Bos Safari. Damn. You do have to install an app, so the the extensions come bundled with an app. Yeah. But, yeah, full extension support, which is, yeah, also really

cool. I I spent, like like, $15 on ad blockers when I was when I was telling you about the the error we were having earlier with the ad blocker not loading a specific route because of the name of it. And we just got people screenshotting us a black screen, and there was nothing that we could find because the ad blockers were also blocking our century. So we had no insights into what was going on, and that was really frustrating. So I just went on a tear, and I found a few people who sent me them. Like, what extensions are you running? And I just installed all of them, and I finally found one that that caused it to happen.

Yep.

Wild. Awesome. Well, thank you so much for all your time. This was this was really good and enlightening. I I kinda wanna build a couple more Chrome extensions myself now instead of just making them Careers Monkey TypeScript. So thanks a lot.