 You are part of the browser. You're extending the browser experience. People often don't think about it that way. They think about it as like, well, I'm just changing the theme on that website. Yes, but you're, you are doing things that like a website wouldn't, you're part of the user agent. Hi, my name is Patrick Kettner. I'm a member of the Chrome Extensions DevRel team. To my left is friend and colleague Oliver Dunk, another member of the Chrome Extensions DevRel team. And my right is Simeon Vincent, co-chair of the WECG, the Web Extensions Community Group. Simeon, thank you so much for joining us here today. I'd love to talk more about web extensions before we dive into it. Can you introduce yourself to the folks and let us know a bit about you? Sure. It's a pleasure to be here. I, for four and a half years, was working with the Chrome team as a developer relations engineer. I'm currently working on a browser extension focused consultancy incremental software. And I'm also contributing to Firefox. I'm working with Mozilla. So yeah, I have my hands full with a lot of stuff these days. Yeah, no kidding. Yeah, that's something that we've, coming as I'm somewhat newer to the extensions team, we've been able to talk a lot more as you are the kind of the expert of being a co-chair of the standards group, or the part of standards groups, Web Extensions Community Group. It's been really eye-opening experience, at least for me, how small a lot of the community is for something that's so many users. I don't know almost anyone that uses the Chrome browser or Firefox for that matter that doesn't have at least one extension installed. But the development system and even like just the people that work in browsers on the different extensions, it feels like a really small ecosystem. Is that something that? Oh, I strongly identify with that. It is a surprisingly small and kind of tight-knit community. There aren't a whole lot of places where extension developers congregate. And that's actually something I'm really interested in trying to expand and develop over the next year or two. I want to start working on, you know, getting more community group or community events together and actually having people talk to each other about how they build things, what their considerations are, etc. It is a, I feel like software in general is a really small ecosystem. And then each niche within that is kind of a subgroup. Before working on the Web, I was working in the video game industry. And that was definitely a community where everybody knows each other. You see each other at GDC every year. Good people, their names get around at different companies. And the browser space honestly feels like that, but even smaller. And then web extensions within that are an even smaller group. So one of the things that I really like about the web extension community group is, I feel like we're very collaborative, that we talk to each other a lot, that we're very open to discussing ideas and kind of working through things. And that smallness of that ecosystem, I would love to get more people involved, but at the same time, I'm really appreciative of the people that we have. That's actually a great call to action. So for folks who might not be aware, could you actually explain what the community group's model within the W3C is actually? Yeah, I'm not like the biggest W3C expert, but the community group model in the W3C was created in order to enable interested parties to be able to kind of much more easily talk to each other and kind of explore ideas, much more easily than a working group. So working groups in the W3C are kind of the standard group. The standard standard body. Yeah, exactly. So they actually produce specifications and standards that are agreed upon by and browsers commit to. Community groups are not empowered to create standards, but they are empowered to create technical reports, which are basically a formal way of saying, we can write docs. We can write things that other people can then talk about and reference and potentially include in a standard spec. Gotcha. And it's been going for two, maybe three years at this point? Yes. I should know exactly when we started, because I was one of the founding members, but I don't recall off the top of my head. I think this is our, we just wrapped up our second TPAC. TPAC is the W3C's annual conference and it has a terrible name. It's like Technical Plenary and Advisory Committee, but just think of it as the time when people working on web standards get together to talk to each other. Yeah. So all the different browsers, there are things like banks for that are interested and payment APIs or anyone that is really invested on the web gets together at some location all around the world every year and talk about how to make stuff good. That's something I think a lot of folks, especially that might only hang out on like Reddit or Hacker News might not be fully aware that we meet with people from Mozilla, people from Apple literally every week explicitly the extension team and talk about what is going on with Manifest v3 or with any other random API. And TPAC is literally just a little like summer camp where all the people get together for a week. All three of us were just in Seville, Spain last week. As the chair of the committee, a co-chair, thank you so much. I don't want to forget Timothy from Apple. As the co-chair of the WECG, you were kind of one of the de facto leads of that group a lot of ways. You helped organize and lead the discussions. What all did we cover at TPAC? Can you share like what was decided? Yeah, we covered so much in such a short amount of time. It was actually a little bit of overload. So before getting into exactly what we covered, we had a total of four hours scheduled to talk and I think we spent like 25 hours talking to each other. So every day getting together, wherever there was room to be able to sit down and having a six hour pre-meeting meeting. In some cases, that's kind of how it came out. So we got through a decent amount of stuff in the Who's the we actually? Is this all? So the we in this case, the participants working on meeting and discussing web extensions in this conference were myself. So currently unaffiliated officially from the W3C point of view. We had engineering representation from all three major engines. So WebKit, Blink, and I never know what to call Firefox. I should get better at that. Is it Gecko? Gecko, yes. So we had representation from Chrome, Safari, and Firefox. And engineering representation specifically. We had DevRel participants, both of you were there and engaging in conversations. And we had a couple of different browser extension developers that were present. And I think special thanks to them, they gave a lot of insight and context that can sometimes be missing when your leads are focused on how the internals of a browser work, getting that additional context of, but that feels weird. It's always really important. Yeah, it's something that I think is really undervalued by a lot of folks that haven't worked in a browser is how kind of starved for feedback. A lot of extension or a lot of browser engineers are like we work on a problem. We've worked on a new API, a solution, something for a month, not years at a time. And you maybe have a handful of people that give you feedback on it. And then eventually maybe you get hate mail once it actually launches. Like it takes a long time to actually get people's opinions to come through. And yes, the more we can get that from the community, the better, you know, like being able to try out new stuff earlier and tell us how to think is. Now, that's actually something I wanted to talk to you about. When you were on the team, I believe you and Oliver met before Oliver was on the team. We did. And Oliver was a part of an extension company. Do you want to give a bit about your extension background, actually? Yeah, sure. About the transition. I was working at OnePassword as an extension developer. So that was really interesting sort of seeing the challenges that extension developers have. And like I worked very closely with Simeon, especially with the migration to Manifest V3, sort of talking through our feedback and trying to sort of pass on our challenges. And you gave lots of great advice, both like passing that feedback along when it was relevant, but also just showing us ways of doing things that we hadn't considered. And I think that's where the communication is really nice because sometimes there are solutions and like just talking things through like brings those out. Yeah, in the world of I really like developer relations because you have that opportunity to directly help people explore ideas or work through challenges in a way they might not have seen. Because the experience of thinking about how you build your extension is very different than the experience of thinking about how people build extensions or what is possible. So that kind of experience I really enjoy working with developers to talk about their problems and work through them. And that's something I'm actually really excited about. As I'm working with Mozilla, my primary focus right now is on helping extension developers bring their experiences to Android. And that's right. Mozilla just announced that they're going to support add-on extensions or add-ons on their mobile devices. That's really exciting. I am super excited about it. So is that is there feature parity? Like is it something where in general extensions on the web can in general go to Android? By and large, yes. There are some differences. The MDN documentation has a nice table that actually shows kind of which specific platforms and browsers support what APIs. So there are notably some differences, but I think the key difference that the average extension developer needs to be aware of is extensions on Android support event pages, but not persistent background pages. And persistent background pages are the typical model that people you have historically used when developing extensions. Classic like invisible tab where everything's running in the background extension. And it's kind of like the coordinating, you can think of it like a central dispatch that everything is coordinated through or like the brain of the extension. But the key difference here is that an event page is started in response to an event and then will be terminated when it's no longer needed. So it's not persistent the way previously it was always there in this time. And the reason I'm assuming is performance or like what is the actual? As I understand it, the fundamental challenge on Android is its process model. That in Android application can have a single primary process. And then if it has secondary processes those can be reclaimed by the system potentially even while that application is in focus due to memory pressure or in CPU pressure and other constraints. So in order to keep the device responsive, Android may kill your other processes. And this is critical because previously extensions are running in the same process as the rest of the browser. And if a website is compromised, if you have a zero day vulnerability and they're able to escape the memory space of that kind of one one origin's capabilities, it can potentially the attacker can potentially do anything they want inside the that memory space that's shared between all the other either websites or extensions, which means that a compromised extension could do something bad or worse that a website, a compromised website could get access to extension capabilities, which are already above and beyond what a browser would normally give a website. So it is super important to be able to have extensions running separate from web content. And that that primitive is only now coming online for Firefox on Android. So you mentioned cross browser extensions. I think that's a good opportunity to sort of pop the stack and go back to team. We had some really great discussions there. I'm curious. Do you want to share some of them? One that I'm really excited about is some of the discussion we had around moving to the browser namespace as the way for APIs to work across all browsers. Yeah, and that that seems like a relatively subtle or unimportant. Do you want to summarize what that is actually? Yeah, so the short version is that Chrome since it introduces extension model has used the word Chrome as the global namespace for extension stuff. And Firefox, when they created kind of the web extension platform, when they implemented Chrome's model, they didn't want to use Chrome because they're not Chrome, obviously. So they used a generic name browser. And that fundamental tension of which global do you use to access all of the capabilities of the platform has been something that has just kind of been a stumbling block for folks since there began this alignment around this common model. And we made a lot of progress on kind of talking through the set of problems and challenges and how to actually just make browser the thing that works everywhere. So it's not like it's going to happen next month kind of thing. It is a like this is an ongoing conversation and we need to perform some do some work and the web extension community group open some like pull requests on other specifications. But we can see the destination on the horizon. I think when you have it's funny working on the scale of web browsers, when you have billions of users, it's really hard to break the internet. Like we need to make be very sure that when we're shipping code that it doesn't completely break something. I mean, there is famously the array method that broke mood tools. I want to say like a few years ago where it ended up breaking tons of websites and those websites were never going to be touched. And so as a part of introducing a new global namespace on the web, our us Chrome need to make sure that that doesn't break a whole bunch of random websites. Yeah, absolutely. People in Slovakia need to file their taxes or something like there's a ton of due diligence. And so something that seems and is very simple to implement ends up taking months if not years of research. Yeah, I think that's the subtle bit that is very easy to overlook. That it does take a long time to make sure that we're dotting the eyes and crossing the T's and performing the right set of tests. And yes, we're very confident that we're not going to break anything by doing this, by removing something or adding a new thing, both of which can potentially be major stumbling blocks. But I'm very excited that we made a lot of progress there and hopefully actually have no idea about a timeline. Do either of you have a sense of when? Yeah, I don't think so. Yeah, it's nice that we made some progress. I think there's still a long way to go and we'll see how things pan out. I think our team was able to confirm that we can ship it. And I think anyone that's worked at a large company or development in general knows that 90% of the work can sometimes making sure you can do something before you actually ship it. So it's definitely much sooner than I would have originally anticipated. I don't mean to walk back your state, but please, we may be able to ship it. Yes, we know that it's not an impossibility. Right. Yeah, we have confirmed that it's not impossible. And that's a huge win, a lot of times. Absolutely. Getting back to the question about what we covered in TPAC, so talking about the browser namespace, that was a huge one. We dove into alarms in trying to make the behavior consistent across all browsers. There are some weird discrepancies that have come up in the past couple of extension community group meetings. Alarms was something that was surprising as a newer person out of the group here to extensions. I think historically when I think of extensions, I think of web development. And so if I want to run something at a random time, I'll do set timeout, 10 minutes, run the code. But we can't do that with extensions, right? Right. So I think there are two considerations. One is the difference between an event context and a persistent execution context. As long as a web page is open, as long as you have a tab open, the set timeout makes sense. But if you have boundaries there, potentially the browser closing and starting up again, or the background context for the extension going away and coming back, then a set timeout no longer works. You need another mechanism. And that's where alarms comes in. It's an extension-specific API to get notified about some work that you want to do in the future. It's a part of the web extensions platform that works in Safari and Chrome and Firefox, et cetera. But it's at a high level, it exists. But at a very low level, there's all those different differences that end up biting people occasionally. And we were able to iron out some of those issues. Yeah. So one of the kind of surprising things that I didn't realize was an issue until it was brought up in the web extension community group was Safari, when they began adopting the web extension platform, they implemented alarms different than Chrome had. Notably, I believe the summary is, and please correct me, Safari was using wall clock time. So effectively, the system clock, whatever your computer says the time is, that's what they were using to calculate when an alarm should fire. And Chrome had kind of more of like a relative time passing system. So it was possible for some weird things to happen where if you shut down your laptop and then say you schedule an alarm to fire in one minute, you close your laptop for two minutes and then open it. What happens to that alarm that you had scheduled? The behavior was inconsistent across browsers. And then that kind of forced us to come back together and say, but what should it do? Wait, we know what Chrome does. We know what Safari does. But what do we want the- What's the correct thing for the platform? Exactly. And I think one of the things that we talked about at TPAC was agreeing that wall clock time is probably the right way to solve this problem. And more broadly, having it behave like set timeout and set interval do on the web also probably makes a lot of sense because that's what developers are coming from and what the behavior that they're used to working with. And that actually I would say if we were to try and pull out a theme from TPAC, I think that was one of them was like, let's embrace the web APIs. Let's try and stay as true to that platform as we can and only deviate when we need to. Yeah, that was a major through line. No, it's been really encouraging, I think, to see how much investment there is to do the right thing to a lot of extent. When it comes to the web extensions platform, I think all major browsers, all minor browsers, even the ones that don't use other engines are shipping, they want the extension ecosystem to thrive until it exists for a long time. And so we need to make a whole bunch of decisions like this to make sure there's not weird random bugs that end up hitting people. One of the very interesting considerations to me about the difference between the web platform and the extension platform is the constraints are a bit different. Ideally, we want things to be able to, an experience that somebody provides in an extension to be able to last as long as possible, but browsers are constantly under development and the capabilities of browsers are constantly changing. Unfortunately, we are less of a fixed target than the web is. The web keeps adding capabilities but doesn't get rid of old ones and we don't quite have that same luxury on extensions. So one of the things that I've been thinking about and I'm interested in exploring is how do we responsibly evolve the extension platform in a way that minimizes the amount of change and the amount of pain that it causes developers while still enabling us to move forward and advance things that may require breakage. Sure. So it's funny that you mentioned that because I feel like you and I have actually talked about how to evolve the ecosystem over time and specifically, I think we were both a real big fan of Ember, the JavaScript library, how they handle releases. Yehud has done a really amazing job there. As a co-chair of the WECG, you could in theory help steer all of web extensions to that model and I think it'd be great to share why you think that is a particularly attractive model. Yeah. So I'm going to kind of slaughter or I'm not going to do a great job of summarizing how their approach works but in essence, when they introduce a new capability, they add a new method or namespace or whatever to the Ember framework in parallel to the things that already exist and then when they make a breaking change, when they move from two to three, say, they essentially cut off all the things that have been deprecated and only carry forward the things that are kind of the intended platform for the future and I find that approach really interesting and I'm kind of surprised that more people don't do it because it does very much embrace this idea of we're constantly moving forward but we're going to give you as long of a runway as we can to help you transition and also in that time, prove out the new thing is actually better than the old, provide documentation, migration guides and give people enough runway to successfully transition. Responsibly evolving a platform is a genuinely challenging thing but I'm really, I've actually reached out and talked to them a bit about how they work and I have some documentation I need to follow up on in terms of better understanding their process but I do kind of expect that I will in the not do this in future write something up, share it with the web extension community group and kind of suggest maybe this is a model that we want to think more about formally embracing. And to add some context there, I think one of the things that has us all thinking about this is manifestv3. Of course. So we had the transition from MV2 to MV3 which was the newest version of the extensions platform and I think we all generally agree that there are things that went well but also a lot of things that could have gone better. So I'm curious, do you want to talk a little bit about some of the challenges that you saw developers facing and how do we try and make future changes better for developers? Well they always be as painful as last time. I certainly hope not. In the web extension community group I definitely want to talk more about how we evolve things and how we approach new capabilities and platform revolution in order to minimize that pain. But some of the things that have been challenging for extension developers is moving from a persistent background page which is I think the vast majority of the community use that as their fundamental model to service workers. So not only are you transitioning from persistent to event based, you're also transitioning from a page context to a web worker context. And that is a very critical difference because so many web capabilities are exposed on the document object model on DOM. So many APIs that people use like integrating with the clipboard or I don't know back forward navigation. Those are exposed on DOM, not like JavaScript APIs. And essentially what web workers have access to is like core JavaScript APIs plus a little bit of extra. So there were a lot of capabilities that weren't directly available in service workers. And over time, as developers were running into issues, the Chrome extension platform needed to kind of evolve in order to make things easier and have additional grants, make things possible that wouldn't be otherwise. So I think the particular capability that I want to highlight in this context is on the Chrome extension platform, there's a new capability that came on, I think, within the past year. I don't remember the exact timeline. Please correct me if you recall. Which? Offspring documents. Chrome 107. 107. Yeah. Yeah, that's not that one. That's four. It's about almost a year. A little under a year. Get memory. That was quite impressive. Offspring documents are critical here because it provides a document context where you can continue to use those web platform APIs and makes it possible to communicate between that and a service worker and for the offscreen document to have a lifetime independent of the service worker. So it's still not persistent. It's still kind of event-based and related to a particular job that you're trying to do. But critically, it doesn't have the same lifetime concerns and considerations as service workers and it has access to those web platform APIs. So you mentioned lifetime concerns. I feel like one of the things that our team has struggled with the most in the last five years that Manifest V3 has been going on is communicating why the changes were going on and what we were actually addressing. I think one of the biggest ones is really around performance also secured in other things. But performance is especially impactful with background pages. So what was the issue with the background page performance-wise, especially coming from someone focused on mobile extensions now? Yeah, so obviously these days I'm thinking about Firefox and Android and the especially constrained environment there. But I think there were similar concerns on the Chrome team where people are using Chrome on a wide variety of devices with a wide variety of capabilities. You can get a pretty low-end Chromebook and it still has to be able to do all the stuff that Chrome does. You know, unbound number of tabs that are being interacted with unbound number of extensions that the user has installed and ultimately a constrained performance budget of how much you can do per cycle. And I guess a more limited number of cycles per second. To some extent you two are formally the better equipped to answer this than I am. But my understanding of a lot of the constraints were that because you had persistent background pages, those are essentially fully active tabs that exist in parallel to what the user is currently interacting with. And browsers do a ton of optimizations in order to minimize the amount of work that they're doing at any given time. So like freezing background pages, throttling them, sorry, background tabs. Yeah, like if you had a loop running every half a second on a page, if you switch it so you can't see it, it might slow it down to every five seconds. So that just improves battery life, it makes sure that other processes aren't being interfered with it or anything like that. But with a background page that's effectively a fully tab that's invisible, you can optimize those the same way. Yes, and that constraint, because they're expected to respond instantly and have open ports with all of the different pages that they're communicating with, people don't think about it this way, but basically every extension you have installed is another open tab that's visible to the user at all times. And not visible. They're not visible, but it behaves like from a performance point of view, from a browser engineering point of view. It's as if you had a tiled set of windows and you're only interacting with one, and that's the one the user thinks is their current tab, but you still have to deal with all of that resource consumption. And that is hard. It's very hard to optimize that away. And there are compounding factors that each extension slowing things down 10% could get to an exponential growth easily. Yeah, I mean, I know that I think we're all kind of power users of extensions. I believe I've cracked 100 recently of stuff that are installed. And obviously we're beyond the edge case, but if you have five or 10 extensions, which is really common for a lot of Chrome users, that those performance issues can really add up quickly. Especially when a lot of extensions are built by hobbyists who aren't necessarily considering the biggest impact of performance over time. Something that is kind of a double-edged sort of extensions. You're incredibly powerful, but with great power comes great responsibility. Certainly. That's I think one of the really interesting things to me about the extension space is you are part of the browser. You're extending the browser experience. And people often don't think about it that way. They think about it as like, well, I'm just changing the theme on that website. Yes, but you're, you are doing things that like a website wouldn't, you're part of the user agent. And all of that responsibility of being, being performant, properly handling user data, making sure everything is secure and safe, you now take out that responsibility. And that, that is also challenging to do well. Absolutely. I mean, there are people that's been their entire careers focused on that space. I mean, like you said, we're theoretically some of the biggest experts for Chrome extensions. And it's kind of scary how much you can still learn every day. Like, there's so much there. And especially, I feel like a lot of the partners we work with and developers of, you know, some of our individual people, some of them are huge corporations that are entirely focused on extensions. They have a lot that they can teach us. We were lucky enough to have someone join us at TPAC and give their guidance. And actually, the off-screen document, like you mentioned, I feel like it was a direct result of feedback from the community. Absolutely. That gets back to, we on the Chrome team at the time thought that we had kind of a right set of trade-offs and capabilities. And as people developed on it, and as they experimented with it and tried to build things, they could concretely say, no, this isn't working for us. And then we went back and said, all right, how do we make sure that it does work for you? What do we need to do to extend and enhance this? I'm curious, actually, you mentioned off-screen documents. We've also made a number of other API changes. I feel like I'm definitely seeing that developers who previously struggled to migrate to Manifest V3 are finding that it's now easier to do that and that more of the capabilities that they needed are present in the platform. Does that match what you're seeing? Yes, absolutely. I think one of the big constraints there early on was, I mentioned before, service worker lifetimes. And there's been a ton of work that Chrome has done to relax the hard limits that were in place and make it easier to have a set of work execute and for your extension service worker lifetime to extend until you're able to responsibly shut down, which is fundamentally different before there was a five-minute hard limit. No matter what you were doing at five minutes, you will stop. It's moved to almost a magic show now where it feels like, in general, I feel like extensions and really all of the web platform mostly just wants to do what's intuitive to end users and with service workers for extension specifically, I think the whole purpose is that they're there when the developer wants them to be and they go away when they're not. It's that kind of perfect balance of utility and performance and the five-minute limit was wrong on that. It was something that we were able to iterate and learn with feedback from the community. Yes. It's something where when you're making a browser engine that's the perfect browser engine, but it's not necessarily the perfect browser engine for users. So if there's one takeaway, developers, feedback is critical. Absolutely. Please tell us what we need to do better. So I'm lucky enough to have your phone number. How do they do that, though? I'm assuming we're not going to put that on the screen right now. Oh, sure. How do folks actually contact you or us or anyone else? What's the best way to get feedback on extensions? Yeah, I would actually defer to you two on how Chrome prefers to receive feedback these days. Sure. I mean, we can do a roundtable. I mean, personally, I don't care if it's, you can put my phone number up. We can do smoke signals. It doesn't matter. Worse, like I mentioned before, we're starved for feedback. Like we do get feedback, but it could be 10 times as much and it still doesn't feel like it would be enough. You know, when there's so many APIs that people are literally building their livelihoods on, that if they're struggling against it, like if they have to spend an extra week to in order to do every release because of some kind of problem with the API, they could have literally talked to us 10 years ago over lunch and that might have completely changed. Like it's really, really outsized the amount of, it's like an avalanche effect, you know, throw a pebble and by the end it's a giant snowball of impact that people can have. And so personally, however they can reach me, my name's Patrick Kettner, literally every social media contact, please contact me directly. That's how I feel personally. Like it doesn't matter how you do it, get it to us. I think scalable-wise, the mailing list, Chromium extensions, mailing list is sort of the de facto extensions communication. It's definitely the best way to stay up to date with what's going on on the platform. Yeah, was there, do you have a particular way you like to get feedback from the community? Yeah, I'd call out a couple of things. In terms of changes on the platform, we have the known issues page, which you can find on developer.chrome.com. That's a great place to keep on top of things. If you find an actual bug in the platform when you have a feature request, then just the Chromium bug tracker is a great place for that sort of thing. CRbug.com. Yeah, CRbug.com, exactly. And then the WebExensions community group. I think that's a really nice place for specific feedback that's more about the ecosystem, the warrants, the concept of extensions. Yeah, I'm curious actually, how do you think about that in terms of the distinction between a bug that should be filed against a browser or a bug that should be brought to the community group? Yeah, so in the case of things like inconsistent behavior, where one browser implements a particular set of behaviors and another browser has a slightly different or slightly inconsistent approach, I feel like that's good content to discuss in the WebExensions community group because maybe it's not clear from the platform what should happen and we need to discuss that amongst the browser vendors and figure out how to proceed. I think if there is something that clearly doesn't work as documented in the browser's documentation, in particular, focusing on the difference between MDN currently has a lot of Firefox more specific content, which is something we're trying to make more generic and developer.chrome.com has a lot of, it has Chrome's official documentation for what the APIs are and how they should behave. If you found inconsistent behavior with what's stated on developer.chrome.com, you would open a bug on Chromium's issue tracker, CR bug. And that is a great way to tell browser vendors that thing doesn't work. Of course, please search, make sure that you're not duplicating existing issues, but once you've verified that nobody else is talking about your particular problem, open an issue. Yeah, it's the better formed feedback is the more exponentially helpful it is to web browsers, like having specific test cases if there's a platform problem, having specific links to documentation bugs, especially test cases as to how they're walking. Test cases, I think, from my point of view, are one of the most critical things that you could do. Being able to see... Makes it a lot easier. Reproduced demo of exactly the bug that you're talking about, as opposed to saying, go install this extension, now navigate to some particular submenu. It's much harder to figure out what the problem actually is. I think the idea of starring a bug is also worth talking about. Absolutely. So, if you come across a bug that's already been filed, it's really tempting to add like a comment saying, plus one, or this affects me. And as much as we appreciate those, it adds noise to the bug. So, there's actually the ability to star a bug. And not only does that keep you notified if there are updates, but it will also increase a counter for us. And that's a really useful metric to see impact. I think, whenever we chat to the engineering team, if we can say, this bug is the most starred bug in the bug tracker for extensions, that's a really compelling case for... We should look at fixing this. Yeah. I mean, I think anyone that looks at the bug tracker for Chromium will see there's bugs that are almost as old as Oliver. Like, it's a very... There's a lot on there. It's kind of a Sisyphusian task to address. And so, by its nature, it's something that we constantly triage. We look at every bug that comes in, and some of those bugs that are 11 years old don't get touched. But sometimes when it ends up impacting folks in a way we didn't expect, then all of a sudden, that priority goes from a P3 to a P0 or P1. And so, starring a bug is one way that helps our team... Or any browser, really. I mean, the WebKit Chrome or Firefox, it helps us properly prioritize what's important to the community because the whole point of web browsers is for web developers. In terms of sharing feedback, I think, as we were saying, browser-specific issue trackers are great for bugs in weird behavior in a specific browser. I think the Web Extension Community Group is great for thinking about the platform as a whole or talking about things you wish you could do or things that are not as ergonomic as they should be. And coming together as a group, all of us as a community, to talk about how we move things forward. Right. Because ideally, Web Extensions work the same, like the same way that a website, if you have a website, you open it in Firefox, you don't expect it to be different if you open it in Chrome. Right. We want Web Extensions to be the exact same thing, in general. Mostly. Mostly. Yes. Obviously, there's differentiation, speciality of each browser. But in general, the dream is that basic extensions would be great to be interchangeable for the most part between browsers. We're not quite there yet. We're working towards it. Sure. And if we bring feature requests to the WECG, rather than individual browsers, there's much more likely that we all get improved at the same time. That actually brings up an interesting angle about Web Extensions and the ecosystem. We're a bit different than the Web in that we don't have 100% compatibility or we don't need as much agreement on how to move things forward. And I think that is an area that we need to explore in the Web Extension Community Group, how we approach allowing browsers to differentiate and expose browser-specific functionality, but also how we evolve things in the same direction and reduce those inconsistencies and incompatibilities over time. So that's getting back a bit to how we were talking about evolving the platform and making breaking changes. That's one of the things that I'm thinking about and really just need to carve out time to write up a bunch of words and put it in front of other people and say, does this make sense? And if not, then how do you have any other ideas on how we can approach it? Yeah, no, I mean, that's really all it is. It's getting ideas down and talking about them, getting feedback from people, from the community, saying, is this what you want? Because I feel like a lot of times with new APIs, new features, they might be completely different between browsers, but conceptually, at a very base level, they can be the same. Like, we were talking about before having a new API for new tab pages so that if you had a replacement for a new tab page in a browser, you could have access to, like Firefox has the pocket articles that exist at the bottom of the page. Safari has all kinds of like your recently read articles or other widgets. Is there a way that we could maybe bring those to extensions so that custom tab pages could have them and be able to have the same user experience? But the color you want or your custom backgrounds or whatever they want to do. Just give the extension developers the way to make the best experience possible for users. And that's something that we want to make sure that we're not, like, hurting any of the browsers. We're not making or taking away anything that makes them special, but we're actually, you know, celebrating the things that make them unique and something in a way that we don't necessarily focus on the web platform where we want kind of uniformity. Extensions, we can make each platform the reason people like that individual browser all the better. And that's something that I think is really kind of unique about web extensions and exciting to see it thrive so much. Yeah. I think that is one of the things that I also really like about this platform is making the browser you love better, whatever browser it is. We've spoken about bugs. We've spoken just now about feedback. One thing that I know engineers would love me to share is, like, please test across different channels that each of the browsers has. So I know, like, on Chrome, we have, like, Chrome Canary all the way through to Chrome Stable. Firefox I think has similar with Firefox Nightly. And then Safari has Safari technology preview. And getting feedback about things that aren't working as a developer would expect in earlier channels is, it gives us a great opportunity to look at those things. And, like, sometimes if we have a new API, like, for example, having access to new information on the new tab page, then getting feedback on that before we ship it in Stable is really useful. Absolutely. The best time to be able to change something. Yeah, and especially even for existing stuff, testing your existing code in those dev channels because occasionally there are breaking changes. Like, recently, Chrome, I don't know if you saw, deprecated... Or bugs. Yeah, or bugs, all the better. Yeah, like, Chrome recently deprecated WebSQL. And so it's no longer available as of Chrome 119, I feel like. And there's a handful of extensions that actually use WebSQL inside of it for a database, effectively. And all of a sudden, just didn't work. And we do try and catch those ahead of time. We did. We're not perfect. We proactively, we did proactively outreach to all, like, 1092 extensions that happen to use WebSQL. And we were able to make sure that didn't happen. But if you weren't pre-testing things, you just wake up one day and your extension will be broken. And then at best, you would be able to get a fix in for the next version of Chrome, which could be two months before it ships. And that's a lot of time for your users. If you're building a job out of this career, that's huge. So just testing early, giving feedback early is really, really impactful. Absolutely. And you can make sure that while the engineers are focused on it, they can continue to iterate. I think it's also worth noting sometimes people think it's not worth providing feedback because nobody's going to pay attention to it. Yeah. But as you were saying, browsers are very interested in hearing how things are going. It all gets seen. Yes. We have to prioritize. Yes. We do get a lot of feedback about particular things. Like you said, some things we don't get enough feedback. Some things we maybe get too much feedback. Yeah. But definitely just follow the feedback. And then it all gets seen and we can triage it and decide how to prioritize. Yeah, absolutely. Yeah. We don't always have time to reply to everything though. I think we have a bit more of a luxury on web extensions that we are able to be a bit more engaged down the part of the platform. But in general, every single thing that anyone files a bug on Chrome, some human is reading it if not several dozen or several hundred. You know, it's something that everyone looks at and really does shape things. If we can point to actual use cases saying that this API is broken for these users, that's huge. That can actually change how we plan the next quarter, the next year of work. Absolutely. It gets something that really is impactful and please, please just give us feedback. So I want to circle back real quick to providing feedback. The Chromium Extensions Google Group is a great resource. A lot of people, a lot of extension developers are talking to each other and Chromies are talking to the community about the platform and how things are evolving. A web extension community group is a great place to talk about kind of the future of the platform and lessening inconsistencies and the direction that we're trying to move things. Issue trackers for the individual browsers are a fantastic resource for reporting individual bugs on those browsers. And I guess on my bias, the Firefox side, the Mozilla Discord, or Discourse, the Mozilla Discourse is a great place to share feedback and talk to other extension developers. Absolutely. Yeah, and it's really something that is, again, incredibly impactful, like get involved and give us feedback and it can really change the way the web works, I feel like is really the case. Now, completely shifting gears, something that I feel like was kind of the hot topic for a lot of TPAC across all the groups, not just extensions, was the impact of AI on the web and how that'll actually interact with stuff. I think extensions are particularly suited to sort of be the default platform for a lot of AI interactions on the web. Like in apps, you can't add AI to random apps that you're using. That's true. You have to add it to the operating system. On the web, there's no other platform that's so ubiquitous that anyone can create an extension that just gets injected on any piece of content. Do you think there is a deeper place within extensions for AI? Like I said, something that could be added to the platform, or is this more of a service-based thing? Is it something we go to our bards, our chat GPTs, using remote APIs? Yeah, what's the future look like with extensions in AI? I'm not going to prognosticate too much because this isn't my particular area of expertise, but I do think that there's a place for local models running inside extensions. And I think that there are there's potential for the platform to better accommodate those use cases to have capabilities that are targeted to being able to load a model or quickly rehydrate it. And I think that's worth exploring in the web extension community group among individual browsers. I think there's also a really interesting opportunity for extensions to call out to these kind of services to BARD and chat GPT and whatever else folks are working on because you can do things with a data center that you can't do locally. And you know, that's the story of the web, right? But I do think that there's unique opportunity for both to integrate. Okay, my personal interest in having the local stuff is offline capabilities. Meaning like the local stuff meaning all AI happens on the device. Yes, or using an extension to enhance your web browser and add some AI features that if you have a model that can cross multiple pages and that extension is able to inject into the different websites and kind of synthesize data from across multiple sites. On behalf of the user and ideally with the user's consent and understanding. I think that's a really unique and interesting opportunity. And the trouble is I think it can be a bit challenging right now with the set of APIs how they exist for the platform what the extension platform allows that you're starting up the model potentially more than you want. So it becomes a more expensive operation. It's tricky though because these are large complex pieces of software that are working on constrained environments. You can't keep everything in memory at the same time. It feels to me like there's opportunity to explore what we could do there. Yeah, absolutely. I think it goes back to what we were saying with testing out stuff and getting early feedback because it feels like with all the AI stuff we're kind of at the similar to the early days of the web when there were so many things and that gave us the Dom like you mentioned which was a terrible API for a lot of times like a lot of stuff was just shoved there because it could and that's kind of an example in my opinion at least of an API that's not great. We've slowly evolved over the last 30-ish year 35 years away from it and I certainly don't want to see that mistake repeated with AI where we've rushed to get a bunch of APIs just to have them immediately and then we end up spending a quarter century trying to undo our quick mistakes. I'm really excited to see the growth here. I hope us on the WECG can come with something that we can bring AI to the web and web extensions though I am also really interested in what the community what folks out there think is there something you're looking for from the platform with AI with anything else that's missing let us know it's a good chance that you can actually tell us what we're working on next year. I think everyone's heard the stories of like somebody using an AI tool to like write an essay for them or even to like help them write code have you like falling into that group yet or is it still something you haven't explored as much as you'd like? A little bit of experimentation not too much with actually having having it generate tons of content I've mostly used AI tools to try to seed my own creativity and introduce other directions that I might not have thought about otherwise but yeah for me it's been mostly kind of a starting point or very early on as opposed to like I'm going to now use this to scaffold my entire blog post and then I'll just tweak a couple words to make it grammatically correct yeah you know that's funny my default assumption you know as someone that's very passionate about developer relations work is how can this affect our job like how can we make the web better how can we use it and so I think the default assumption I think a lot of folks on our team was to ask it questions about web extensions or whatever they're working on and judge its answers like is it good is it bad and it was funny how many times there were the whose nations that were coming through and I feel like that's something that's going to be real area for our team and for all developer relations and for standards groups and everything else and how to maybe properly train models so that when developers look to them for the co-pilots or other developer tools they're not giving completely incorrect information where it seems close enough to reality to where it just leads them down the wrong path it's something where I don't really know how we're going to address that but like I guess local models are things that where they're actually focused on individual things maybe a Chrome extension documentation model could be something that could help people but it's something that again I'm really excited to see but also really interested to what more people are thinking about on this I think what really excites me about that is that I think often these models make the same mistakes that we all do yeah using the same information they're trying to come to the same conclusions absolutely and so I think rather than our focus being how do we create the best AI tool which I think is something that is going to happen regardless take from the community I think we should just focus on let's make sure our documentation is answering the questions that people have absolutely and like if we can do that then hopefully the models will have the information they need and everything else will follow on from that yeah it's definitely an exciting time I'm not scared yet I can tell you that much yeah I would love to keep going but I think we're actually getting close to time so before I completely cut you off is there anything you want to share with the folks at home how they can get more feedback or how they can contact you or anything else yeah if you are new to browser extensions and are looking to get started my previous experience with the Chrome team I'm very biased developer.chrome.com is a great resource to learn about building extensions as is extensionworkshop.com the kind of Firefox specific website to learn about the platform MDN is a great resource and I'm very excited to explore keeping our data the web compatibility data up to date great feedback conversations there we mentioned the web extensions community group a number of times how do you get involved with that so you can join the web extensions community group by visiting w3.org and searching the community groups for web extensions community group web extensions is one word and once you join then you can add issues on our github repository and help us join in adding tags and modifying content to make sure that we're up to date we try to keep a in github issue on the on our github issues you can also participate by creating issues on github and adding topics to the agenda to be able to discuss it in our subsequent meeting we try to keep a agenda issue pinned on the repository that way it's super easy for people to jump in and and contribute all browsers and other external partners meet every two weeks to talk about whatever is on the agenda so yeah and if you join the group you can attend those meetings that's all it takes thank you so much for joining us here today Simeon I look forward to talking to you again soon and I look forward to sharing another video soon as well have a good one