WEBVTT 00:00.000 --> 00:08.960 The next talk is about where are we with our arms or something similar to that? 00:08.960 --> 00:09.960 Have fun. 00:09.960 --> 00:11.960 Thank you very much. 00:11.960 --> 00:18.840 Hello everyone, it's a pleasure to be here. 00:18.840 --> 00:21.040 This is my second time at Boston. 00:21.040 --> 00:24.080 I will pretend that I know what I'm doing. 00:24.080 --> 00:29.960 Last time Rob and I well ran over, I think this time I'm going to come in under. 00:29.960 --> 00:32.480 So we can actually have Q&A this time. 00:32.480 --> 00:34.040 So my name is Simeon Vincent. 00:34.040 --> 00:39.520 I'm a developer relations engineer on the Firefox Atoms team and I want to give you a quick 00:39.520 --> 00:44.280 recap of some of the stuff that we've been working on, some kind of major features and improvements 00:44.280 --> 00:49.560 over the past year and some of the collaboration that we're doing with other browsers. 00:49.560 --> 00:55.680 So let's start on a answer in the question. 00:55.680 --> 00:59.640 What is the current state of Firefox Atoms and spoiler? 01:00.160 --> 01:02.960 I'm biased, but I think it's pretty good. 01:02.960 --> 01:11.640 And we are continuing to work on it and make it even better, both the Firefox team and the surrounding 01:11.640 --> 01:15.520 community that we're very happy to be a part of. 01:15.520 --> 01:23.240 So some quick stats to set ground rules or kind of expectations on where we are today. 01:23.240 --> 01:34.520 At the moment we have about 46.5,000 extensions published on AtomsAtmosil.org and that number 01:34.520 --> 01:40.840 I believe is growing, I don't have historical data right now, but about a year ago, actually 01:40.840 --> 01:48.440 December 2023, we launched support for Android or more accurately, we opened up extensions 01:48.440 --> 01:50.520 to be generally available on Android. 01:50.520 --> 01:58.240 Where we had a limited curated tiny set of about 20 add-ons and since then we've gotten 01:58.240 --> 02:06.760 a total of almost 100,900 add-ons available on Android and we've seen steady growth 02:06.760 --> 02:13.520 in this category that developers continue to adopt at a pretty good clip and they continue 02:13.520 --> 02:18.960 to publish useful extensions that people are getting real value out of on a regular basis. 02:20.760 --> 02:27.960 Add-on usage continues to grow over the past five years, you can see a steady increase 02:27.960 --> 02:36.240 in the number of individual users that have at least one add-on installed in the browser. 02:36.240 --> 02:39.440 And I think this one is pretty interesting. 02:39.440 --> 02:43.960 The distribution of users that have a given set, these numbers are kind of small, but 02:43.960 --> 02:50.400 so the first column is people that have zero or a hidden number of add-ons. 02:50.400 --> 02:57.480 Sorry, the number of users that are using a given add-on, the next category is up to 10 users 02:57.480 --> 03:05.440 and then we have 10 to 100, 100 to 1000, 1000 to 10,000, et cetera. 03:05.440 --> 03:09.560 What this tells me is that we have one of the things that makes add-ons really interesting 03:09.560 --> 03:13.720 and powerful is that there's an incredibly long tail that people are finding 03:13.720 --> 03:21.120 value for themselves and for their small communities and being reaching users that way as 03:21.120 --> 03:27.800 opposed to just everybody piling on to the kind of current most popular experience. 03:27.800 --> 03:35.360 I think that it's also a unique differentiator compared to other ecosystems. 03:35.360 --> 03:42.080 Over the past year, we've done a number of improvements to the Firefox client, the platform 03:42.080 --> 03:49.120 and I want to start with a quick look at some user experience improvements that we've made. 03:49.120 --> 03:54.400 First, user scripts is a feature that we're going to be relaunching. 03:54.400 --> 04:00.680 There was an existing user scripts API and in collaboration with other browser vendors 04:00.680 --> 04:06.600 and members of the community, we've developed a new user scripts API for the latest version 04:06.600 --> 04:08.640 of the platform, manifest me three. 04:08.720 --> 04:15.080 In Firefox, we're going to be shipping that in a belief, we're flipping the flag for 134. 04:15.080 --> 04:21.680 136, thank you, Rob, as the engineer has been working on that. 04:21.680 --> 04:26.280 So I want to take a quick look at the user scripts experience here. 04:26.280 --> 04:34.440 As you can see, when you first install in add-on, or in this case, the add-on is exposing 04:34.480 --> 04:40.080 the ability to opt into using the user scripts API in its options page. 04:40.080 --> 04:45.480 By default, when you install it and add-on that uses the user scripts API, it doesn't just get access to it, 04:45.480 --> 04:51.360 because it's a very dangerous, very powerful capability with power comes danger. 04:51.360 --> 05:00.440 We want to keep user safe and informed, so users have to choose to invoke this grant access to user scripts API. 05:00.440 --> 05:05.320 The extension is going to request access from it when the user clicks the button. 05:05.320 --> 05:12.520 And then the user has to choose to allow the add-on access to this capability. 05:12.520 --> 05:17.880 This says, allow unverified third-party scripts to access your data. 05:17.880 --> 05:22.200 Again, very dangerous, we want to make sure that the people who are doing this know what they're doing. 05:22.200 --> 05:26.560 If they don't, then we want to make it hard for them to do it by accident. 05:26.560 --> 05:36.560 And once you've enabled that checkbox, you can allow it, and then you now, that extension can now give you these powerful capabilities. 05:36.560 --> 05:40.280 I also realized I didn't actually say what users scripts are. 05:40.280 --> 05:46.720 The current user script model is essentially like a piece of JavaScript that you inject into a page, 05:46.720 --> 05:52.800 and that JavaScript usually is developed by a third-party, but you can write it yourself. 05:52.800 --> 05:57.240 And it will allow you to customize how a web page behaves. 05:57.240 --> 06:03.600 And users scripts notably, Greece Monkey, was a really popular user script manager. 06:03.600 --> 06:10.240 That the developer of Greece Monkey worked on Chrome's extension model, 06:10.240 --> 06:20.360 and then Chrome's extension model is what Firefox adopts, and is the current platform that's being adopted across all browsers. 06:20.360 --> 06:31.800 So in addition to that user flow, you can always go to the add-on settings page and manually enable it yourself as opposed to the extension having to ask you. 06:31.800 --> 06:38.800 This is important because you have control, even after you've installed it, even after you've enabled it, 06:38.800 --> 06:49.320 you can go through the permissions and make sure that the things that you want the extension to have access to are the only things that it has access to. 06:49.320 --> 06:54.400 In the past year, we've also done some pretty big improvements to the debugging experience. 06:54.400 --> 07:04.160 There have been a number of bug fixes, but the one that I want to call out in particular is the debugging experience for background scripts. 07:04.160 --> 07:10.560 So there was kind of a longstanding bug where as you're developing your code and making changes, 07:10.560 --> 07:16.760 you would save a change, you would refresh it in Firefox, and you would not see any update in DevTools. 07:16.840 --> 07:20.200 And that affix for that has recently landed. 07:20.200 --> 07:27.720 So now, after you make a change, you can click the reload button and put the console.log there a few years at the end, 07:27.720 --> 07:30.680 because that was the new line of code that I added. 07:31.880 --> 07:38.520 Content scripts are a piece of code that the extension can inject into the websites that you visit. 07:38.520 --> 07:45.000 And we've had a couple of improvements and new features related to content scripts over the past year as well. 07:45.000 --> 07:56.600 Specifically in DevTools here, we now have the ability to go into the sources tab, select the gear icon, 07:56.600 --> 08:02.680 and then select ShowContents scripts, and now you can see all of the content scripts. 08:02.680 --> 08:10.120 Previously, you had to go into the extensions debug experience that was separate from the pages you were visiting. 08:10.280 --> 08:13.320 And needless to say that was a little cognitive dissonance. 08:13.320 --> 08:18.760 So this is another great improvement to just the general productivity of building extensions. 08:21.160 --> 08:27.080 Another thing that has recently landed, I believe it was in 135 and not 100%. 08:28.680 --> 08:32.680 Is the ability to switch the context for the console. 08:33.640 --> 08:41.320 So specifically here, we just loaded the content script so we can see the utility asked from privacy 08:41.320 --> 08:43.640 Badger in the bottom right. 08:44.920 --> 08:52.680 I just, in this case, type of browser, because browser is the global namespace that extension 08:52.680 --> 08:58.920 capabilities are exposed on. And normally, the browser global doesn't exist on a web page. 08:59.000 --> 09:03.800 That's only exposed to extensions. So what you can see here is in the bottom right. 09:03.800 --> 09:08.360 You can click on this selector, and we can go into privacy Badger specifically into the 09:09.560 --> 09:16.040 content script context for it. And then when we type type of browser, we can see that this is now an object. 09:17.800 --> 09:21.080 The global variable that we expected to exist is now present. 09:21.480 --> 09:29.320 The other thing I want to call out is over the past year, we've had a good bit of collaboration 09:30.040 --> 09:37.400 with other browser vendors. A quick crash course on web standards. I know a decent number of people 09:37.400 --> 09:44.120 here are involved in this space, but some folks may not be. So the W3C is kind of the premier 09:44.120 --> 09:51.560 organization's web standards. The worldwide web consortium, they are the body that handles a lot 09:51.560 --> 09:58.040 of standardization of web platform APIs. They have a variety of groups and kind of substructures 09:58.040 --> 10:04.280 where specific people are bringing on different areas. We have about three and a half years ago 10:04.280 --> 10:10.760 established the web extensions community group, which is a body, as the statement flies, it's a 10:10.760 --> 10:18.360 community group as opposed to a standard body. But this is the forum that the various browser vendors 10:18.360 --> 10:25.160 and members of the community developers have been coming together to talk about what the platform 10:25.160 --> 10:31.720 is and where we want it to go in the future. So our kind of main goal, the main things that we're 10:31.720 --> 10:38.200 focusing on are reducing inconsistencies across implementations and evolving how browser extensions 10:38.200 --> 10:44.120 look and feel. And if you're at all interested in this process, we meet every week, 10:45.720 --> 10:51.800 meetings, everybody's favorite topic. We meet every other Thursday at 8 a.m. Pacific to discuss 10:52.360 --> 11:00.040 issues and try to advance the current state of the platform where we have also for the past two years 11:00.600 --> 11:06.920 been joining in the W3C's annual conference, T-pack. It's a terrible name. I don't want to 11:06.920 --> 11:12.040 explain what it means. Pretend it doesn't exist. It's the W3C's annual conference. We're also meeting 11:12.040 --> 11:17.640 on the other half of the year at face-to-face meeting. Last year Apple hosted the first one at their 11:17.640 --> 11:23.720 San Diego campus. This year Mozilla is going to host one and Berlin. And we're going to be 11:23.720 --> 11:32.120 formally announcing that in just a couple days. There's much more that I wish I could talk about, 11:32.120 --> 11:37.240 but I think that we're going to go over to questions now. If you're interested in getting into 11:37.240 --> 11:41.240 extension development, I have a couple of resources, strongly encourage you to visit the 11:41.880 --> 11:47.400 Mozilla discourse in the Adon's channel. Ask questions. I'm happy to do whatever I can to 11:47.400 --> 11:53.080 support your work and explorations there. Extension workshop is where you can find a lot of information 11:53.080 --> 12:00.920 about developing Firefox Adon specifically. And obviously, MDN has general web platform API documentation, 12:00.920 --> 12:05.560 including on the web extension platform. And if you have questions for me, 12:07.000 --> 12:13.400 you can reach me on Maskevon and Luskai. And I also hold open office hours where you can 12:13.400 --> 12:17.720 schedule time with me to talk about your development experience. No, no, they're going to ask 12:17.720 --> 12:28.120 the questions now. Thank you. Do we ask questions? 12:35.080 --> 12:44.360 I noticed that, well, many extensions have used the permission to access the data on all websites. 12:44.600 --> 12:50.040 And it's very capability to, like, revoke that permission. Because many of those extensions 12:50.040 --> 12:54.600 are still usable without that capability. Is it possible to just revoke, 12:54.600 --> 13:00.280 whatever they're asking in their manifest, some of them? If in Firefox, it isn't currently 13:00.280 --> 13:07.720 possible to, that's actually kind of a lie. It is possible to revoke access, but it's not as granular 13:07.720 --> 13:13.800 as we would like it to be. That's a feature that we're investigating, I believe, more generally 13:13.800 --> 13:19.880 at the standardization or cross browser development level. I think we all recognize that 13:20.760 --> 13:26.840 access to all pages that user visits are super powerful and dangerous, especially passive access. 13:26.840 --> 13:33.240 So it's something that we want to improve, that we want to change, but it's also really hard, 13:33.240 --> 13:38.680 both reclaiming or restricting the abilities capabilities that people currently have. 13:38.680 --> 13:46.360 Nobody's excited to give up power. And figuring out how we can build a better extension 13:46.360 --> 13:53.320 experience in a way that minimizes access is an ongoing area of discussion or exploring ways 13:53.320 --> 13:57.480 to design new APIs that will hopefully enable that stuff in the future. 14:00.600 --> 14:06.600 Hello. I would like to ask you that extensions, which modify new new 14:06.600 --> 14:15.560 top, lost their ability in last versions to clear the URL bar, and there's open issue for that, 14:15.560 --> 14:21.160 and there is no closure to it. If do you plan to look into it or do you have people decided 14:21.160 --> 14:27.000 if this API will come back? I am not familiar with that particular change. 14:27.800 --> 14:33.320 If one of the Firefox engineers here is able to speak to it, otherwise I'm happy to follow up with 14:33.320 --> 14:43.560 you asynchronously to look into it. There are a handful of people that work on the add-ons team here, 14:43.560 --> 14:47.560 that probably has more technical expertise on the details. 14:53.560 --> 14:59.560 This is question from the chat. I see some extensions of Firefox Marketplace have this kind of 14:59.560 --> 15:07.080 disclaimer. It's not active, monitored by for security, by much help, make sure you trust it 15:07.080 --> 15:12.680 before you're installing it. How does this happen and how can the developer avoid this? 15:15.400 --> 15:20.680 That, I don't think I have a great answer there. So, by default, 15:23.080 --> 15:27.080 when somebody publishes a new extension, it will fall into that category of extensions that are 15:27.080 --> 15:36.200 unmongered. Generally speaking, I believe the scrutiny applied increases as user count does, 15:37.080 --> 15:43.960 but I actually would prefer to defer to Andreas, if you don't mind, to give a little bit more detail. 15:44.920 --> 15:49.080 Andreas, as a member of the add-ons team and focuses on operations. 15:50.280 --> 15:56.280 One way to remove that banner removed is through our recommended extension set. 15:56.280 --> 16:01.960 So, we have a curated set of extensions that Mozilla officially recommends. They get a shiny new batch, 16:01.960 --> 16:05.880 they get boosted in the search results, and they also have that banner removed. 16:08.760 --> 16:14.680 Actually, on the extensions workshop site, if you go to that website and search for recommended extensions, 16:15.960 --> 16:20.520 you will find a page about what recommended extensions are, what our criteria are, 16:20.520 --> 16:28.360 for considering recommended extensions, and also how to apply for an extension to become recommended 16:28.360 --> 16:33.800 either your own extension or an extension that you just like as a user, you can nominate your own 16:33.800 --> 16:35.640 or any other extension that you found. 16:41.800 --> 16:43.800 I was hoping I would be able to find it as you were talking. 16:46.120 --> 16:47.720 Alright, thanks for the presentation. 16:48.280 --> 16:53.800 I only have two extensions installed. One of it is authored by Mozilla itself. 16:53.800 --> 16:57.560 I was, because it's hard to trust third-party, so I narrowed down. 16:57.560 --> 17:03.640 Is there any sort of framework to basically promote an add-on into Firefox itself? 17:04.280 --> 17:05.640 Is it not the end of it? 17:07.320 --> 17:12.920 I'm going to say not exactly. In fact, I think there's been a history of taking some features 17:12.920 --> 17:16.680 that were originally implemented in the browser and moving them into extensions that are 17:16.760 --> 17:20.840 separate and maintained. The multi-account containers is an example of that. 17:26.200 --> 17:31.320 Again, I want to look to the engineer and team to say, 17:31.320 --> 17:35.560 do you have more experience on the rolling something into Firefox? 17:36.600 --> 17:41.800 Or has there been any capabilities that have been developed externally in the added? 17:47.640 --> 17:54.280 For the audience, Luca, stop. 17:57.880 --> 18:02.120 So we had a reply, but it was an audio. We're going to get the same reply on audio now. 18:03.720 --> 18:08.600 So screenshot is the best example that comes to mind. It started as an experiment, 18:08.600 --> 18:13.320 so it was user installs the extension. It was a test pilot, I think, experiment. 18:14.280 --> 18:20.120 Then it was promoted to be like a system add-on, which is like same code-based, but integrated 18:20.120 --> 18:24.760 into the Firefox build, so you don't need to install it. And more recently, we 18:25.800 --> 18:30.040 turn it into an integrated component, so it doesn't leverage the extension framework 18:30.040 --> 18:33.080 is more integrated, so it's kind of more performant in some ways. 18:36.520 --> 18:41.880 I think there have also been a couple of projects, most notably PDFJS. I think isn't 18:41.880 --> 18:46.680 integrated into Firefox and Chrome. It's like correct Chrome. 18:49.480 --> 18:52.120 There's another question. We'll come back to it and it was like it. 18:53.320 --> 18:58.200 Yeah, I'd just like to echo the first commenter with, we need some kind of restrictions, 18:58.200 --> 19:03.160 because there's no reason my crypto wallet extension needs to access my bank in website. 19:03.160 --> 19:04.840 So there needs to be something there. 19:04.840 --> 19:11.400 In particular, I think one of the features that we've been considering is the ability to 19:12.280 --> 19:18.600 add exclusion sites, so you can specifically prevent extensions from accessing your most sensitive 19:18.600 --> 19:25.000 component. And the second is just saying thank you to whoever approved the video background fix 19:25.000 --> 19:31.720 in the early set of Firefox mobile, because it managed to sell the browser to my friends. 19:33.480 --> 19:34.680 It's a perfect YouTube plant. 19:34.680 --> 19:41.720 Just building on that, I have one of the things that I really like about extensions. 19:42.440 --> 19:48.520 Why I'm kind of dedicated to this space is they enable user choice to a degree that you don't 19:48.520 --> 19:54.680 see in other computing environments that we give people the opportunity to choose the experience 19:54.680 --> 20:00.760 that they want on the web. And I think that's part of why we continue to see growth in extension 20:00.840 --> 20:08.040 adoption across the browser users. I think there was a question in the back. 20:10.040 --> 20:18.520 Sure, coming. And that's the last question, because if we don't stop questions, then the next talk can't happen. 20:22.520 --> 20:28.360 I noticed that extensions don't fall, the cannot use SSO information. 20:28.360 --> 20:38.440 And so you come to have single sign-on through an extension. It doesn't have access to the 20:38.440 --> 20:41.480 guru or sticket. Is there any way to get fixed? 20:44.200 --> 20:49.320 I'd be happy to dig into that a bit more. I don't quite follow because if extensions have 20:49.880 --> 20:57.000 host permissions for the single sign-on origin, then they have access to the cookies on that. 20:57.000 --> 21:02.520 And it should be possible to implement a single sign-on experience in a way that works in a browser extension. 21:04.200 --> 21:07.480 Thank you very much.