Jonathan: Hey folks, this week David Ruggles joins me and we talk with Sylvester and Brian about Firefox, the original open source browser. Something of a perpetual underdog, but maybe it's time to take another look at. You don't want to miss it, so stay tuned. This is Floss Weekly Episode 812, recorded Tuesday, December the 3rd.
Firefox and the future. It's time for Floss Weekly. That's the show about free Libre and open source software. I'm your host, Jonathan Bennett, and we're going to have a lot of fun today. First off, we've got the one, the only David Ruggles, the David Factor, the, the original David Ruggles, as opposed to all of those clones running around out there.
Hey, David, welcome.
David: You're just trying to bring in every single one of my handles from every possible source. Oh, I'm excited to be here today. In proper form, I am calling in from a Firefox based browser, so this is, this is awesome. I'm excited. In fact, I plan to do a lot of listening and not a whole lot of talking.
Jonathan: Oh, well, but I mean, you're kind of the, you're the, you're the expert co host this time. You're, you're the Firefox user. So you gotta, you gotta be on the ball to be able to jump in and ask questions. All the things that I wouldn't think to ask. I can do that. Yeah. So for those that don't know, that are not watching the schedule the way that we are, our, our Guests today are Sylvester and Brian of the Firefox project.
So from Mozilla and boy, there's a lot, there's a lot going on with browsers these days, and I am just thrilled that these guys are willing to be here and chat about it. There's. There's some things to talk about. So let's, let's go ahead and we will just go ahead and bring them on. So Sylvester and Brian, both welcome.
Glad to have you both. Thank you.
Brian: Glad to be here. Thanks. Thanks for having us.
Jonathan: Yeah. Let me start with Sylvester and just kind of give us the rundown of like where, where are you in Firefox? Where are you in Mozilla? Well, how do you, how do you fit into this, this thing that we all know and love?
Sylvestre: So I am, I am.
I started at Mozilla 11 years ago, and now I'm a director of engineering. I'm managing an organization of about 50 people. We do release management, release engineers, OS integration, engineering workflow, and some security work also. So we do a lot of things, and we touch a lot of different parts of the project.
All
Jonathan: right. And then, Brian, same question for you. Kind of help us get the mental map. Where do you fit into the organization?
Brian: Yeah, I'm a senior principal engineer working on Firefox and Gecko, the web engine that powers it. I joined Mozilla in 2013 and I've worked on a whole bunch of stuff from kind of dev tools to the desktop front end to platform and recently performance and a whole bunch of other fundamental stuff.
Jonathan: Yeah. Okay, perfect. Perfect. So both both very senior engineering types, which we love. We'd love to be able to ask the engineering questions. But before we get to engineering, I think there's some, there's some interesting history stuff to talk about. I don't think we've ever had like Mozilla or Firefox on the show.
So let's, let's talk about some ancient history and Firefox and Mozilla used to be Netscape. Is that, is that fair to say there's at least a connection to Netscape?
Sylvestre: Oh yeah. In a while, right? So we just celebrated the 20th birthday of Firefox a few weeks ago. Basically Firefox started on the ashes of Netscape.
So, you know, Microsoft decided to ship IE with Windows for free, and back in the day, we, Netscape was sold. Two users. So obviously it Netscape took a hit and some people decided to refactor on Netscape into what we call back then the Matia project. And then the project was renamed to Firefox and here 20 years after.
So, but it's also a, Firefox was really a revolution. We think about it like most of us in that call are pretty old. And remember what it in the day when had popups everywhere. And you didn't have tabs. So if you wanted to look three different websites, you have to open three windows. Now we have tabs and a proper blogger.
Firefox is a browser that created that.
Jonathan: Yeah. Boy, there's some, there's some cool history there. I remember Firefox 4. It's kind of a big memory I have because I was just getting active like in things and on the internet. And I remember when Firefox 4 was sort of the big push and I don't remember when that was.
Early, early 2000s I guess. And that was, that was a big deal because you know, there were cool things happening in Firefox and it's been a long time ago now. And I was, I was talking with David before the show and, you know, you kind of look at the, the, the current browser wars and the, the how shall we put this, the market share of Firefox is maybe not quite as big as what everybody would like.
And it, it occurred to me, Firefox has been in this position before. This is, this is not the first time that Firefox is, is approaching the the market as the underdog. And this in some ways is a comfortable position for you guys. And one of the things I think that we can dig into maybe today is like what, what cool things are coming because you know, when you're, when you're a bit of an underdog, that kind of gives you a bit of freedom, I think.
to to experiment and try things out. And so I'm, I'm hoping that you guys will have, have some neat things to talk about that you're kind of looking at with that, that you know, things coming, things down the pike where Firefox is going to once again, be sort of shaking up the entire ecosystem.
Brian: Yeah. Yeah. It's, it's a, it's a, tough position to be sort of the independent choice and not be the default on on most, most devices. But I think at the same time, in terms of, I think that's important for the platform in terms of having an open interoperable platform and then being able to compete on, you know, basic browsing fundamentals, performance, security, stability you know, managing web compatibility, and then you know, adding a bunch of, a bunch of new features to just make getting through that.
Getting through the day better, you know, people use their browsers for all sorts of things today. And so there's a bunch of stuff coming down the pike in the next year that we'd love to get into.
Jonathan: Yeah, but before we, before we dive into sort of what's coming, maybe let's, let's talk about some more of the like fundamentals.
So Firefox has been around for 20 years and If, if I forget this, David, you particularly, I'm gonna put a pin in this and you help me remember, if I forget, I want to talk about Rust too, because that's something big that Mozilla has been involved in. But I guess first, what, how, how big of a project is Firefox?
Like what, what does the line of code look like? How about, do you know, just off the top of your head, like in the, in the ballpark, how many commits there are? Let's, let's chat about the size of the thing.
Sylvestre: Sure. So it's one of the biggest project that we can find on the planet. Like we we love the expression.
It's not rocket science, but here it might be more complex at rocket science at time Because when you think about a brother you have to run untrusted code all day long and you have to keep the user safe And secure so for firefox to give you a scale of what we have i'm looking at the number We have more than 10 000 Contributor over the history.
We have about 1000 contributor per year. We have about 31 million of code. Of course, some of them are platform specific. So you don't always get all those code in your binary. Some of the code is Android specific. Some of them are Mac specific, et cetera. And we are close to 1 million commits in the code base.
So when you think about it software that has been alive for 20 years, how many of those are still alive? The Linux kernel.
Jonathan: Yeah.
Sylvestre: So windows. And Photoshop, there's only a few. So yeah, it's crazy the scale of what we do.
Jonathan: Yeah. You know, we, we had, we've interviewed some of the people that have been around for 20 years and there's, there's projects that you wouldn't necessarily think of, you know, like the core utils, you know, some of those have been around for a long time, Emacs and VI, but.
Most of those have gone through, like, big shakeups, and you know, we're not still using the same Unix core util source code from the Unix days, right? People have re implemented that now a couple of times. And there's now, you know, this interesting move to re implement it in Rust, which is really fascinating.
I have put my foot in my mouth a few times and said that Mozilla created Rust, and I've been corrected each time. No, no, no, no, no, that was this professor guy. And Mozilla just came along and used it. But, is it fair to say that Mozilla is responsible for a big part of where Rust is today? I think that's probably fair to say.
Sylvestre: I think Graydon was a Mozilla employee when he started that project. Oh, so I think it's a, I think it is a Mozilla product. Like it is, maybe I'm showing off, but it is something that Mozilla created and we had like 10 or 10 employees at some point working full time on Rust. And we are still contributing to Rust in many different places.
So to me, it's a Mozilla product. Correct me if I'm wrong, Brian.
Brian: Yeah. And to, to add on to that, I think nowadays it's a separate sort of spun off into an independent foundation and has huge traction in the ecosystem from tons of, you know, companies and open source supporters and, and and, and whatnot.
But I think in terms of what it was sort of designed to do was to be a systems programming language that could build a browser and certainly to, to my knowledge it was sort of incubated and started at Mozilla.
Jonathan: Yeah, does that put Mozilla in an interesting place as kind of still well? So is Mozilla still sort of the main stakeholder?
Are they are they sort of the The the place where rust still lives and does that put Mozilla kind of in an interesting place as like the engineering experts?
Brian: So now it lives in in an independent foundation separate from Mozilla. It was sort of spun out To, you know, to, to broaden the ownership and sort of governance of the project some years ago, but we still have a user still involved in in the, in the core language and we are landing new Rust, you know, every day.
So we're certainly a big fan to continue to be a stakeholder.
Jonathan: Yeah. Are, are you just adding new features in rust or is there kind of an, an active development process to port things over from the old C code? Or is it c plus plus? Honestly, not sure. Are you actively porting old bits of the code base to rust?
Brian: Yeah. So it's mostly c plus plus. Mm-Hmm. , we are not, we don't have a concerted effort to kind of port you know, the millions of lines of existing code. But what we do is when we have a chance to redo a component. Or some sort of nice encapsulated portion of code. We tend to reach for that just for the security and sort of ability to parallelize code and so on.
So we had a really big project where we took the Stylo CSS engine out of Servo, the engine that we had sort of incubated. Within Mozilla and put it into, into a Gecko. And so that's a huge sort of rust component that handles all of the CSS, you know, parsing and matching and interaction with the layout engine.
That's entirely in rust. And we've seen amazing performance out of that over the years. And we've done the same with. Parts of the rendering stack, I think, crash reporter and, and other components.
Jonathan: Yeah, very cool. I, I, I have been saying for months, if not years now that, oh, well, I really just need to sit down and learn rust at some point.
And I have finally with the the 2024 advent of code, it's a, it's a fun little project where you get a tiny little code challenge. For every day for December up until the 25th. And, and I got to looking at that and they go, Oh, we support every single language. I was like, okay, it's time to learn Rust then.
So I've done the first couple of days of the advent of code and Rust. And I now understand why people, when they first start learning Rust say that it drives them nuts, but then it makes them better programs. I'm beginning to understand what they mean by that.
Brian: You'll have to ask Sylvester you know, about that one as well.
I'm sure he's got some stories from that.
Jonathan: Oh, I'm sure. All
Sylvestre: right. It's not always easy to start with Rust for sure. Yeah.
Jonathan: Well, it's just different. It's a different, it's a different paradigm, really. Because, you know, with C, you return an object, like you return a string, or a value, or whatever. And with Rust, you have this idea of, we're going to return either a value, or We're not going to return anything.
And Russ doesn't have an idea of a null. So you've, you've got this, like this week. So coming at it as a C plus plus developer, you've got this weird thing that you've got to handle. And then, you know, the first time you start using it, it's like, do I need an ampersand? Do I need to do a dot unwrap? How do I actually get it?
The thing,
Brian: I'll be interested to hear how the rest of the advent goes for you and sort of, as you get through, I assume it gets more challenging as it goes. So. Maybe it'll be a good ramp up.
Jonathan: That, that was, that was my hope. That was my hope that it would be a, a good sort of soft introduction. And there, the, the nice thing about it's they're bite-sized problems, right?
Like the first one was you're give, or let's see, the second one, I don't remember exactly what the first one was, but the second one was like, you're given. five numbers, and you have, and it gives you a very simple pattern, like each of the numbers have to be within two, and they all have to be either incrementing or decrementing, and so you've got to do some things like, all right, so we're going to take this, this text file, we're going to split it by new lines, and then we're going to Split it up by whitespace, and then we're going to convert each of those into an integer, and then we're going to do some simple math on the integers to make sure.
And then, you know, return a number and then do a, you know, a running calculation. It's all very, very simple stuff, but the fact that you're doing it in a new language, for me at least, I'm doing it in a whole new language to me. So it's like, over half the time I'm spending there on Google trying to figure out, alright, how does, How does one convert from a string to an integer in Rust?
And what kind of thing is that actually going to give me? But it's, it's, it's been fun. It's been a lot of fun. But it is very, it is different for this, this old C programmer.
Sylvestre: I can, I can share an anecdote about Rust. Given the scale of Firefox, we have, we need to develop plenty of tools around the product itself.
So for example the crash management is one of them. So we used to use bpa, and BPA was not very maintained and upstream was not really accepting our patches. Mm-Hmm. And it was quite old and hard to maintain and we decided to be right. It in rust. And and I, one, one of the anecdotes is that we, we wew wrote a pt B, so the Microsoft par Microsoft debugging format.
We wrote that, we rewrote the parser in Rust and it significantly decreased the load on the server, which were doing the parsing of the crashes, to the point that I think that some Microsoft team are now using our crate that is doing PDB parsing for their own format they created. And we have those kind of anecdotes with Rust everywhere.
Rewriting in Rust sometimes can be expensive, so it's not something that we always want to do, but the return on the investment can be huge.
Jonathan: Yeah, yeah, definitely makes sense. Okay. So what about contributions is, are there still quite a few contributions that come from outside of Mozilla? And what does that process look like?
Like how difficult is it to land something in Firefox?
Brian: Yeah, I think Sylvester may have the numbers pulled up on sort of the, the outside contributions. We, we definitely get a lot of outside contributions. I think in terms of difficulty. It's, you know, it's a browser. So I think finding, we try to identify sort of good bite sized places to start. I think we put a lot into the tool chain to make it easy to, you know, pull down, bootstrap all the dependencies and do the build.
I was just looking, you know, at some of the sort of. Depending on how fast your machine is, you could get built as fast as sort of four or five minutes or, you know, 20 plus minutes or 30. It just depends on the much. It's actually improved since I started at Mozilla a lot. We've invested a lot in that and then it's, it's open source.
So it's MPL licensed. Anybody can, can kind of pull it down and make contributions. And so I think finding the right. You know, we have, we have pages and stuff and a chat server if you want to hop in and get involved with the project, but we've gotten a lot of great contributions from people outside of Mozilla and continue to.
Jonathan: Yeah. So you mentioned the MPL license. Let me cover this real quick and then I'll toss it to David. What, what kind of license is MPL? Is that based on the GPL? Is it a BSD style? You know, how permissive is it?
Sylvestre: It's very close from the Apache. License. It was written by Mozilla. I think it's one of the first licenses of that style.
So it's a, it's, I wouldn't say that, but maybe to take a shortcut about license, not to base it about license it's between GPL and MIT. So we get some protection. It's very flexible. So you can fork Firefox and do what you want with it.
David: And David, feel free. I know that this is the Firefox show, not the Rust show, but one question with the public contributions that you're seeing, are you seeing a uptick in Rust contributions over C It's
Jonathan: a good question.
Sylvestre: I'm not sure. I, I'm not. You know, when I'm bored, I'm going between two meetings. Most of my life is spent in meetings. And sometimes between two meetings, you want to do something concrete and writing docs or talking with colleagues. So sometimes I'm running good first bug. And I know that I'm opening Python and C and Rust.
And usually, so, So those good first bug are taken very quickly by a contributor. Most of them are clippy fixes, that kind of stuff. With clippy, it's a static analyzer in Rust.
Brian: Yeah, and I don't know within the tree. That would be an interesting query to run, I think. We also have a lot of projects that are outside of Mozilla Central.
So the main sort of Mercurial source tree. That get vendored in that we still maintain. So, for example, we're working on a WebGPU backend which is a new API in JavaScript that gives you sort of platform independent graphics programming. And that is a separate GitHub repository called WGPU. That's, that's Rust based and is used by other projects as well.
And so we have that there's a quick stack. There's a lot of and then there's a lot of code sort of that's, that's very independent from the browser in terms of the repository itself that I think have also picked up some good outside contributions.
Jonathan: Yeah. So kind of in this vein of talking about the the, the various contributions and what gets worked on how, how does Firefox, how do you guys make the call?
Like what, what do we spend our, our development time on and kind of related to this? One of the I guess I could call it a criticism, suggestion, scuttlebutt. Something people say not just about Firefox, but about a lot of different projects, is I wish they would spend more time on the fundamentals and not work on and then X, Y, or Z, whatever that person is frustrated about at the time.
And so sometimes that's, I wish they wouldn't waste their time doing AI integration or, you know. And what's ironic about this is people have said that about different things over the years and Sometimes those criticisms turned out to be well founded and sometimes those criticisms were very not well founded.
And the thing that people were, you know, wasting their time on turned out to be the next killer feature. And so that's something I found is that it's very hard to know. But inside of Mozilla, like what, what does that process look like? How do you guys come to that conclusion of, okay, this is the thing we're going to work on.
And I leave that to the two of you to figure out which one is, is more appropriate to answer the question. Both of us, we have different
Sylvestre: perspectives. Brian, you want to start? Well, I think,
Brian: yeah, in terms of, in terms of priority, an enormous amount of effort goes into fundamentals. I think that's been true over the years.
I think. We've had a huge focus in the last couple of years on performance in particular that we could we could talk about sort of speedometer three benchmark and a lot of wins we've seen on that. But, you know, performance security stability. We put Mozilla puts an enormous amount of the investment into Firefox into those things.
They're not always super visible which is 11 difficulty with that. But I think they're they're super important. Like, in terms of performance. Advancing the web platform, both for the, you know, millions of Firefox users. And then also just for the competition in the, in the ecosystem, it's important that you're sort of never slow down on that stuff.
And that can be basically an infinite amount of resources you can take onto those things. And so, of course, you have to make decisions. On priorities and prioritization, especially for a new feature development. So I think in the, in the coming year, you know, there's a lot of investment planned in just improvements for getting through the day on the browser.
So things like tab groups vertical tabs for people who want that with the sidebar that has kind of more rich. Capabilities to interact with the web page, better you. I for managing user profiles. So for completely independent profiles, you could always kind of switch between those in Firefox, but making that really pleasant to use and then, yeah, building features that are using you know, newer technologies, AI inference, you know, such as local translations for language translation alternative text captioning and so on.
And so I think that would be an area interesting to, you know, to dig more into. But I'd also, you know, love to talk more about the performance end of things. And also maybe I'll give Sylvester a chance to jump in there before we go deep on that. Yeah, sure. Yeah.
Sylvestre: One of, one of the things that we, we have to keep in mind when we talk about browser roadmap and prioritization is that a significant part of our work is defined by the startup bodies.
So when there is a new, when there is a new startup coming, we, If it makes sense and if our competitors and friends are implementing it, we have to implement it. Otherwise, you are going to get some window on some website saying not supported on Firefox of things that we used to have back in the day. So we, we have some of our roadmap is driven by, by those standards.
So it's always a trade off. And to be honest, when, when you, you mentioned some comments that we can read online, we read those comments and we have also the tools to Those discussion internally, like, is it the best use of our time? Is it the best way to advance Mod Mission? So, as you know maybe not always the business know, but Modia is driven their mission with, and our goal is to keep internet healthy available to everyone and the public resource.
And all decisions that we make on Firefox and at Madia in general are, are based on that mission statement. So Brian mentioned performances. We have web compact, we have offline translation, privacy processing translation. So those kinds of things are clearly what what is advancing the web.
Jonathan: So Brian obviously wants to tell us about performance.
And so I'm going to, I'm going to let him, I'm going to give him a little space. Brian, what, what is, what's a recent performance win that you are proud of? What's something that's coming down the pike when it comes to performance?
Brian: Yeah. Yeah. Thanks. Thanks for that. Yeah, I think. So we had a, a project actually with, with with all of the browser vendors.
It's, it's not, not the standards based, but kind of standards adjacent project to ship a cross browser benchmark. So obviously people have benchmark browsers for a really long time. We got together and worked on a new benchmark called Speedometer 3 in the last couple of years and have shipped that shipped that this year.
That really focused on kind of end to end user journeys. And so one hazard of benchmarking as, as people probably are aware is you can create these little tests that are not indicative of the real world in any way. And then you optimize those tests to no end and it actually doesn't really help anybody.
And so we wanted to build a benchmark that was really end to end. Like it, it opens a webpage, it renders a chart, you measure kind of how long it takes to do. These different things. So I identified a bunch of use cases, vetted all the code work together with the other vendors to put that together and then sort of set off individually to go compete on that you know, a solid kind of.
framework. And so we, we have an amazing set of performance tools internally. I think that, that lets you sort of take profiles, share them, a great sort of web UI and user experience to share and pinpoint exactly what's slow here and there. And it's really satisfying work, I think, to kind of go and you take a thing, you see exactly where it's slow and how you make it faster and you go you know, work on the code to make it faster.
So a bunch of examples, I think. One that stands out is there's a JavaScript feature called proxies, which is kind of a weird metaprogramming feature. Where you can wrap an object and then sort of intercept any call into that object and like customize it before it happens. And we, when it shipped, it was not used really.
And so all we did was just focus on correctness for the feature and we had never noticed any usage in the wild. We had never heard complaints about our performance. As part of the benchmark, we updated to the latest view JavaScript framework, and it turned out we were like very slow at this test and it was, you know, very concerning.
We're landing these tests that were really bad at, and we started to look at it. Well, they started to use the proxy feature because it's kind of convenient for this, like, reactive programming model to, to intercept calls and know when some state changed. And so that was like evidence that this thing is used in the wild.
Then we went and we, you know, made sure everything happened in the JIT and made it way faster and. You know, land of the change and move made the benchmark faster, and we start to see improvements on real pages, you know, real user metrics and so on from stuff like that. And so there's just. You know, hundreds and hundreds of bugs like that, that, that we've done in the past couple of years.
And I think you may not notice any individual one as a user, but all in all, you know, when you press a key and the text appears quickly, or you click a link and the page is still responsive, you can feel it. And it makes a difference. I think in a, in a in a, in an incremental way, when not, not just Firefox, but everybody, all the browsers are really pushing against that.
Jonathan: Yeah. So something comes to mind with that is. What about on the browser? Like how much of the, how much of the code base is and I know there's some interesting questions with the browser. We'll get into that in a second or excuse me, with, with mobile how much of the browser code base is shared on the mobile platforms, like on Android and then even on iOS.
Brian: Yeah. So we split the the kind of, when we talk about the browser, we split it into two parts. One is called content and one is called Chrome. Kind of confusingly, the browser Chrome is like the tabs and the URL bar. And so. The content is on on desktop and Android is rendered by Gecko. The Chrome, so like the tabs and URL bar on desktop is actually also rendered by Gecko.
So it's, it's a web app. This actually kind of blew my mind when I started and joined Mozilla. Is I was like, okay, so how are we at a feature here? And it's like, oh, well, it's HTML and CSS, basically. And so, so when you're like typing in the URL bar, there's pop ups. That's all just like JavaScript. It's very nice to write as a front end web developer.
On Android, it used to be done that way. And then we switched to use the native UI controls for the browser Chrome on Android. And then on iOS, we use the native UI controls for the Chrome and we use WebKit for the content. Due to, you know, app store policy.
Jonathan: Right. Now, is that, is that changing? I know at least in, and so here, here's the, the background for this.
I, I don't know how many people know this. Am I going to get myself in trouble? Yes. Apple is terrible in my opinion. And so one of the things that in, in fact, I'm, I'm not sure why it is company A that we have an antitrust suit going on with and not Apple but that's just me. I think David agrees.
Anyway so what Apple has done, as I said, you know, if your browser is going to be in the app store, you're actually going to use our browser code. You don't get to bring your own code. for the actual rendering of the webpages. So for the longest time, when you, when someone runs Firefox on an iPad or an iO, any, any iOS device, you're actually using the Safari code to render the webpage.
And in Europe, there has recently been a, a new law passed that basically says, no, no, no, Apple, you don't actually get to do this. You need to support it. Third party app stores. And so the obvious question that I have about this is, does that change anything for Firefox and are we going to see another version of Firefox show up in one of those third party app stores?
It's
Sylvestre: a good question. So we, we, we are investigating. How much work would it be to have a part of Gecko? So what Brian described, so the core part of Firefox. How much work would it be to port Gecko and to maintain it on iOS? But as you can imagine, it's a completely different platform. So the constraint in terms of performances and integration CI are completely different.
So we are spending time on it. Maybe we will ship it, maybe we won't. It's still TBD, it depends on the ecosystem, the work that we have to do and the next step in the process.
Jonathan: Yeah,
Brian: I'd say we're definitely fans of the direction here. We've been working, you know, with with speaking with regulators, with Apple on the proposal and really digging into the technical fundamentals to make sure that it's sort of suitable for being able to run, run on a device, being able capable for the architectural differences between the engines.
And so there's a lot of work there that we're very interested in and continuing to pursue.
Jonathan: I, as an aside, I am extremely hopeful that the third party app stores will come to other countries outside of Europe. I, I do have a single iOS device and it is I am not using it to its full potential because of that, because there are apps that I would like to be able to use.
There are just. Not available inside of the official app store. So it is what it is. David, you want to jump in for a while and get some of these questions off your chest.
David: Oh, yeah, I've got lots of burning questions. So to back up a little bit when we were talking about your focus and what you're able to focus on, one of the things about Firefox that I love and as I mentioned at the beginning, I am using Firefox right now to have this conversation is your extension ecosystem.
And so, when you talk about, you know, the Chrome of Firefox and some of the, some of the other features, even ad blocking and stuff and you, we can see, like, the moves that the Chromium side of the house has moved away from ad blocking and, and that sort of stuff. So, that has actually driven some interest in Firefox.
But does that ecosystem, of extensions, allow you to focus more on that core speed and that core rendering engine and everything, and kind of watch the extensions to say, Hey. This is where people, there's interest in stuff and maybe it makes sense to like do the tabs on the side in the future, but you can kind of maintain your focus while letting the extension community experiment with Chrome and the other attributes around that.
Brian: Yeah, I think it's a great point. I think just to reiterate, like we, we support the web extension APIs, including the you know, previous or the newest version, the previous version, we continue to support that, you know, ad blockers, all of the existing add ons in the store on both desktop and android. Now that's a somewhat newer development that took quite a bit of engineering work.
And so we big fans of that. And people use that for all sorts of things. Things I think in terms of using it as a way to sort of identify features that people want the direction things are going. I think it's a good point. And there's times where that extension APIs are a bit too limited. I think like we've seen interest in, you know, vertical tabs, tree tabs and so on.
And there's some really good extensions to help manage that. But to get something that's like really tightly integrated into the UI that supports all of the different features, you know, we talked about grouping tab groups, making sure that's a first class thing that works in kind of both modes. It's just really hard to do that when you're sort of here's a surface, render what you want and through the just like anything with an extension API, it's always a bit harder to kind of coordinate changes.
So I think it's kind of a case by case thing, but to the extent that we can. Let the extension ecosystem sort of pave a cow path or show a direction forward on, Hey, this is a useful feature. It's getting a lot of traction. I think that's a great way to go.
Sylvestre: I was looking at the numbers and we have 600 extension on Android. Now you can look at how many Chrome extension you will find on Android. Probably zero. Yeah,
David: definitely. Let's see,
Jonathan: I didn't know, I didn't know that there were extensions on Android. Actually. I'm, I, I definitely need to go look into that because that's, that's a thing that has been missing on, I think all of the browsers for quite a while now is able to do extensions on mobile and there are some times that that would be extremely handy.
So that's, that's a win.
Brian: Yeah. Yeah. Check it out. I think especially, you know, you're concerned about, about bandwidth performance, maybe there's productivity things you want to add into the browser to customize that, you know, download Firefox on Android and check it out and see, see if it see if it works for you,
David: David.
Yeah, not to rehash it, but that's where I feel like if you are able to be successful in bringing Gecko to iOS, that extension ecosystem will be a huge win over there as well. Well, it's
Sylvestre: not only an extension, right? It's limiting our capability to innovate on iOS because we are constrained by WebKit and WebKit is not shipping as Often as as chrome, for example rs and it is limiting the innovation and we have so everybody Like if you as jonathan said earlier if you use firefox or chrome or brave on ios You always get the same bugs as the same bug of the platform.
So Shipping on this platform. We can do some nice, cool stuff with web assembly with we were talking about offline translation using was some advanced security things that you don't have with WebKit. So have plenty of things that you can do when you control the full stack.
David: I actually wanted to ask about WebAssembly and the effort that it took to integrate that and kind of where you see that going because that's becoming very hot in the development ecosystem.
Not
Sylvestre: an easy question. I think it's one of the things where Mozilla was at the beginning of that technology like 10 years ago, we had different technologies. So Google was pushing PNaCl Microsoft at some point was pushing ActiveX. We, we were pushing a a subset of JavaScript called ASM ts, which was high performance JavaScript and then with, with our partners, we coordinated to ship web assembly to a product origin.
So we have been, part of the people who created that technology. Brian, Brian can probably say more than myself about the next step in that space.
Brian: Well, yeah, it's really there's a lot of momentum in that space. And the interesting thing is, it's not all in the browser. You know, you think about it, it's web assembly.
It feels like a browser feature. But I think there's a lot of interest in sort of server side you know performance secure kind of language independent runtime. And so one of the, one of the challenges to my understanding is sort of making sure that the features are roughly aligned and make sense sort of in both of those context.
And then also just honestly, there's a lot of low hanging fruit still to adopt it, even with the capabilities that exist today. Like the, the translations infrastructure I didn't know if that would work when we started the, the project, but the way that works is we, we you start Firefox, we don't ship any code related to translations other than like a small little WASM thing to check and quickly guess what the language of the page is.
And then if it appears that the page is a different language than your Firefox is, then we prompt the user. Hey, do you want to translate this page? It will actually go and download the WASM program off the, off the internet. And so you're not shipping, you know, a couple megabytes or whatever size of the inference itself with the binary until the user chooses to.
And then it will go down with sort of language pair weights, maybe 10, 20 megabytes, something like this, and then you can integrate it really tightly with the browser, because, as I was mentioning, the browser has, you know, a javascript and wasm runtime, both for the front end and sort of under the hood.
And so then we can integrate it, translate the page, you know english to french, whatever it is very performantly, like, it took quite a bit of work to do this, but we've even been able to start shipping that on android devices. And yeah, when I started, I was thinking, okay, doing this sort of an abstraction layer above C Are you really going to be able to run this?
It kind of. In a way that makes sense for a user and they're looking at a page and it's sort of you can, you can see it very quickly kind of work through the content of the page and translate it. So it's really exciting. And I think there's lots of other use cases. You can just build on from there. And it's very secure, portable.
You know, it's not it's not. Included in the binary and so on. So just a lot of benefits to it.
Jonathan: I just, I just went and looked at Firefox installed on mobile on my Android. And I just went and looked at the extensions available. And one of the ones that's there is tamper monkey. And I am now entirely sidetracked because the ability to write little snippets of JavaScript and change websites on mobile is just been forever out of, out of reach.
And I'm, I'm super excited about that. Oh, that'll be fun. Let's see. We, we, we touched, we touched briefly on this and I think it might be worth kind of digging into that, that other browser. I don't know. Is it the browser that should not be named? Over and over in Chromium land, they are, they are changing the way extensions work.
And you mentioned briefly that you guys are supporting both the, the new version of extensions and the previous version of extensions. And I know there are some people that are really up in arms about that change over in the Chromium code base. Is this, is this something you guys foresee happening, like long term is supporting both of those versions of extensions and like, what does, what does that look like going forwards?
Brian: I, I'm not super familiar with this area of the, of the code itself, but I think in terms of extension support in Firefox, yeah, I don't think there's any. Intent to, to change. We sort of support the current set of APIs. A lot of add ons are programmed to those. I'm not quite sure the sort of deprecation plan at what point would it be if you're going to.
Ship it. It's only supported at Firefox. And if so, how does that change people's mind on kind of shipping it? And, you know, I think on some, you know, on things like ad blockers, I think there's some cases where the new model is maybe a little bit less resource hungry. And maybe some people would prefer that.
Whereas the older model is more feature rich and people prefer that. I think in terms of, you know, I think just the users could choose. Which is their preference. So long as the extension is supported.
Jonathan: In the, again, this may be outside of y'all's expertise, but in the kind of extension store for Firefox I assume there's, there's gotta be like some, some checking done for malicious code.
Has that ever been a problem? And, and how, like, how does that get sorted? How often do you see malicious extensions get uploaded and do they get caught pretty much right away before they get offered to users? I mean, I would assume that that's the goal.
Sylvestre: So we have a team who is in charge of doing moderation.
So we, we have a lot of tooling, we have a lot of static analyzer and just kind of tool to verify that nothing bad is happening to the user. But yeah, we, we have precedent of some, some extension being used against the user at the end. Yeah, fortunately, but yeah, we are, we are very careful. So that, that's why sometimes it takes, a few days for some new extension to be approved. It's because we need to make sure that every new extension is safe and is not going to do some crypto mining on the system of the user, those kind of things. Yeah,
Jonathan: and crypto mining is really the least of our worries, right? That's, that's the starting point.
And it just gets worse from there. What about, what about detecting those sorts of things in, in websites? Because like a website gets to run basically arbitrary JavaScript. Does, does Firefox do things like trying to detect crypto miners and JS in a website? Or I know obviously there are some things that are malicious that you guys have to, to stay on top of.
What, what does that process look like?
Brian: Yeah, we there's a built in features called tracking protection that has sort of support for each of those classes of sort of nasty code, you know, crypto miners and cross site trackers and that sort of thing. That's you know, there's a sort of curation process. It's tough because you're sort of on defense with that.
So you have to identify. Which, you know which scripts are doing the tracking, add them to a list, deploy that list and notify the clients. And so it's really a hard problem. A lot of challenges with the browser is trying to sort of understand and navigate, you know, unknown web content. And so it would be great to come up with some kind of heuristic.
Where we could say, okay, we have some confidence that this script is doing something like crypto mining as far as I know, that's sort of in the domain of research at this point. And we're starting to, you know, I would be interested to I know we're doing research on fingerprinting and other things, but it's just so hard because.
The APIs that you might want to use for doing something malicious or the same APIs that you would want to do for something legitimate. And so it just gets into really messy heuristics of, well, if you call it this many times and this long, is there some kind of budgeting thing? It's really messy. It's very hard to do in a reliable way.
That's part of what makes browsers challenging.
Jonathan: Yeah, and even a step beyond that, like, so what would you do? Let's just, you know, kind of game theory this up for a second. You know, say you had a heuristic that could detect crypto mining. Okay, so we're going to block that in the browser. Well, what do you do when someone wants to run a website that that is the point of it?
You have an account, pull this page up whenever you're not using a computer and make a few cents an hour doing crypto mining with us, right? And so then you're in this, you know, you're in this weird position of, okay, well, we have to go and approve these URLs to be able to do it. And oh, that, that gets very, very hairy and complicated very quickly.
And. I mean, I guess that's what that's what it is, though, running a browser. It is hairy and complicated because you have all that stuff all the time.
Brian: Yeah. And then every prompt that you're kind of showing the user at some overhead of sort of explaining and making sure they understand what they're consenting to or not.
And so, you know, obviously, ideally, you would, you would set defaults that are like, right for what you feel is right for users and give them an easy way to change it. But it's super, super hard to do that. In a way when the, when the content is not sort of deterministic or controlled by us, it's sort of decentralized content.
So yes, you're right. Yes.
Jonathan: And then, and then, you know, someone passes a law to try to help it. And the next thing you know, every website you visit has a cookie banner. Click here to accept cookies. Yeah. I, I would love, I would love a, a feature in Firefox could do it. Maybe maybe we make this a web API that says I actually know how cookies work and websites are allowed to do local cookies and please don't show me any more banners.
Could we make that feature work? Well, I
David: think that's going to wind up being a legislative question more than a technical question.
Sylvestre: Well, we are back to the web extension point, right? You have web extension doing that for you if you want. Yeah, there you go. There you go. It's a tricky. It's a tricky thing to do that one.
David: Yeah Continuing on the security questions, though. How How does mozilla which I mean, I know you've got the security bug bounty program Maybe you want to talk a little bit about that But there was actually a news article in the last week or so about rom com out of russia that took advantage Of a zero day in firefox that had actually been patched two months ago So obviously Some of the issue is end users not updating.
So I guess I have two questions that you can answer however you feel. Number one, how, how are you guys staying ahead of those evolving threats and issues in code base? And then two, we just talked about, you know, prompts to the user and stuff. Other than the automated updating, which is built in, unless you build it.
Disable it. Are there any other prompts or things that you're pushing the user saying? Hey, you really need to update
Sylvestre: Well as brian said earlier You have to be careful what you are going to prompt to the user because it can be an annoyance very quickly So you have to be very careful. So we do everything that we can to to help the user to update So for example, you will find firefox on the windows store we have a Debian repo an official one where our binary is going to update the user on every platform on Google Play.
The platform is going to update you. So we are trying to update the user as fast as we can, but there is so much we can do. So what we are doing in terms of security, we are, we are doing a lot of things. So we, the bounty program, as you mentioned, is one of the best way. One of the silver bullet that we have been using for a long time that if one day you want to talk about that into details it's an amazing subjects of fuzzing part of what it takes to fuzz a web browser.
So fuzzing is a technology where you send some correct or incorrectly formatted data into the various endpoints. So sometimes it can be just. It's by spider monkey. So JavaScript, but sometimes it's going to be the API or the IPC or Firefox. So you send that and you see what happens and you manage your crashes.
It is one of the silver bullets that web browser have been using for more than 10 years now And we are using static analysis. We are also experimenting with LLM. Like if an LLM can help us identifying some security issue, but we are investing a lot of money to keep our users safe.
Jonathan: Yeah. I think I'm going to jump in right there for a second.
I think one of the most interesting kind of frontiers and security research right now is essentially LLM guided fuzzing. I think that is extremely fascinating, because, and I'm curious about this, whether you've had this problem as well, we've heard from like the Curl project, where they've had people that have asked the LLM, you know, ChatGPT, find me a vulnerability in Curl, because Curl has a bug bounty and some people like I make money by getting chat GPT to find me bug bounties Well, and of course the person doing it doesn't actually understand what they're doing And so they say, you know, find me a vulnerability and chat GPT will happily hallucinate a vulnerability for them And so I am curious whether the bug bounty project at Firefox has seen some of that But there's been an uptick in you know, sort of fake fake vulnerabilities.
And then on the other side, is that something that you're, you're looking into is this idea of LLM guided fuzzing, because I think that is absolutely fascinating.
Sylvestre: So we do monitor those bugs. I don't know the percentage of of those kind of bug report, but we have a few people that are working on, on those kind of bug report full time. So, but given the complexity and the investment that we have done in security, there is, there are no longer, no hindering foods anymore.
The bugs are usually quite complex when you want to find one. Then for fuzzing, we are investigating because we know that it is the next big thing, and we know that the attackers are listening to your podcast and they know now that it is one of the, one of the tricks to find exploits. No, more seriously, it's obvious that it is a big deal.
I guess currently with Firefox, given the scale, it would be hard. But if you know how it works very well, you can probably find a few. And to be honest, we found a few security issues playing with LLM in Firefox. Sure.
Brian: Yeah, and I think there's a lot of interesting stuff you could do by hooking this technology up to a browser, an automated browser.
You know, when you think about looking for compatibility issues, you know, a site that says, oops, we don't support Firefox, you know. Is there some kind of vision analysis? Could you even for more complex workflows? Like you get a bug that says, here's the steps to reproduce. You know, if somebody does a really nice job filing the bug and they give you a very detailed bullet list of exactly what to do, can you sort of wire up a tool to help you know, validate, capture a performance profile, these sorts of things.
I think there's a lot of things to still explore in that, in that space, in addition to security.
Jonathan: Yeah, yeah, very much. So so I, I have said, I have said before, and I will continue to say that I am eagerly looking forward to the flash in the pan of AI going away because like with every other sort of bubble kind of technology, it's only when the bubble bursts that you really start to see the usefulness of the thing, right?
So like you have the debt, the. com bubble. Which when it burst the internet did not go away It's just people started using it more as a real tool rather than doing dumb things like renaming their city city. com and I I see something very very very similar happening with ai it is it is going to stick around We're going to use it for things but you know, hopefully at some point every company will will get the It will get the pat point past the point where every company feels like they need to make AI do everything for them.
And at that point, we get to see where it's, where it's going to be really useful.
Brian: Yeah, I felt I think the local translation thing changed my mentality a little bit on it. Like, I think I was pretty default skeptical. And when I saw that we with an example, I, I remember having a conversation with the accessibility team at Mozilla, maybe five years ago about the idea of doing auto image captioning.
So if you're a screen reader user, you have a vision impairment. If you're building a website, you're supposed to put alternative text on an image. So this is in the HTML tag, you write alt equals and then you describe what it is. In case the image doesn't load or if the user can't see it. But the problem is most authors don't do that.
And so most images don't have it. And so if you're using a screen reader, You're reading the paragraph, you're reading it, and then you get to the image, and it's like, oh, there's an image there, and then you keep going, which sucks.
Jonathan: And
Brian: so, we had looked into, some browsers had started to explore doing, using a cloud service to sort of send the image up, describe it, and send the text back down, which, it was not something that we were, you know, considering or wanting to do, we wanted to do it locally.
And I spoke with the team at the time, and it was like, no, the stuff is, It's just too bad. Like it's just not helpful. It's worse. It's kind of harmful for users because the descriptions are bad. It requires the super advanced hardware to do effectively. Maybe that was maybe five years ago. And then when we looked at it a year ago, it was like, Oh, my God, you can actually do this now.
And, you know, we want sort of controls around it. Like the user should be informed that this is machine generated, and they should opt into it. But if they do, it's actually a huge service to users, people who are using screen readers and like we've, we've sort of taken the steps to generalize the translations platform, basically.
Into more of a general inference platform within Firefox and started to dip our toes into that image captioning task a bit starting with the PDF editor where it's more like an authoring tool right now, but as we sort of validate the performance and quality of those captions, we're hoping to bring that into the main content for first accessibility tooling.
And so those types of things where it's a very clear user value to the feature, we can do it sort of locally performantly. It's to me, it's just like a no brainer from a product standpoint because it's a good feature. You know, regardless of what tech is sort of underneath it.
Jonathan: Yeah.
Sylvestre: And I would add to that we talked about fancy brand new technology with Rust and WebAssembly, and now I'm going to talk about all the boring tech with PDF.
We in Firefox are not showing off. We have the best PDF reader in Firefox currently. You can do editing of pages and it is fully written in JavaScript. We had only a couple security issue over the last 15 years with it. And if you look at our competitor, It sounds right. And in PDF, one of the cool things that we have been working on is you know, when you, when you, when you have a form and you need to put your signature, you can do it with your touchpad or your mouse, but it's not very good.
And usually what you want to do is you take a picture of your written signature with a pen and But it's hard to do, you know doing image recognition and to, to do the background removal and with with a simple model with LLM with a simple model with AI inside the browser, you can easily.
Identify the signature and convert that into an SVG locally without sending your signature to third party and then you will have a very nice signature That you can insert into your tax form for example, and it is that kind of of of boring use case I would say that that is going to stay after the AI bubble, I think.
And you have plenty of those cases. Summarizing a PDF, for example.
Jonathan: That's actually a very good way to put that. It's the boring use cases that are probably going to stick around. That is very apt. One of the other things that I find so fascinating, this goes back to the security angle, that I find so fascinating about AI is that in some cases it just approaches problems differently than a human would.
And so, you know, if you were to tell it you know, This is maybe a little bit, a little bit more advanced of a, of an example than what we can do right now with AI, but it's, it's close. It's not too far off. So you could say, look at the Firefox source code or, you know, maybe one particular, a function even.
Okay. So if you've got a AI that can pull something from the internet, which some of them can now, you could say, well, look at this function, find me a security vulnerability here, and then write, you know, a, a text input that would trigger it. All right, so this gets back to the idea of doing fuzzing from LLM.
Sometimes, the sorts of vulnerabilities, and even if it's a hallucination, right, even if it doesn't exist, sometimes the sorts of things that an LLM will find is very different from what a human would find, which in and of itself is interesting. And so that may not be quite boring, but I think one of the things we're also going to see is the times where that's useful.
And again, security research is one of those times. It's very, very useful that an LLM thinks, heavy air quotes around that, thinks, it thinks about things differently than the human would. And in some cases, it's an advantage.
Sylvestre: Yeah. And sometimes it is connecting dots that a human would not connect. So for example, it's not exactly fuzzing, but One of the, so we have a partnership with Ubisoft, you know, the video game company, Assassin's Creed and so on.
And one of the experiments that we have been doing with them is using an LLM at video phase. So you send a patch, you say, I'm a Firefox developer. And and I, here is a patch and please tell me how you can improve it. And you have the the LLM, who which is going to tell you, okay, you, you should refactor that one or that code may be duplicated by this one and so on.
So you can do some very cool stuff. And that as a human, you wouldn't think, or a very good reviewer would find it, but it's not always easy to identify what kind of improvement you could do in a patch when you are a reviewer. So I'll ping the reviewer. Not replacing it.
Jonathan: Yeah. Yeah. And so along that same line, something else that comes to mind is you were talking about the alt text for images.
I could see it being useful. And, and I say this sometimes people use the alt text to hide jokes, like XKCD really comes to mind. The alt text for XKCD is. Hilarious, but not actually usually very helpful to understand what the picture is. And so there's this, there's this use case that comes to mind that it's like, even if there is an alt text for an image, you might also want the AI generated one because it might, well, for one thing, it's going to be more useful than the joke that's hidden in the alt text.
But it also might turn out to be helpful in giving additional context as to what an image is. And so there, again, it kind of, it kind of taps into that idea of, well, it, an AI might approach this a little bit differently than a human would, and that can be useful. It's fascinating stuff there.
David: Yeah.
Because as a web developer, I've even seen cases where, you know, you're trying to pass your W3C checker. So you get alt equals image.
Brian: Yeah, exactly. Yeah, yeah, the analysis, we should make sure on some of the analysis, because the analysis I've seen is like empty alt text. We should, we should also make sure to have alt equals image in that list.
Yeah,
Jonathan: yeah.
Brian: The tricky part, you know what would be, that's such an interesting idea. I'm trying to think the user experience of that is like, Maybe, maybe there's a keyboard shortcut when you're hovering or something like this. I've always found picking a keyboard shortcut in a browser is one of the hardest hardest problems.
Jonathan: Yeah, yeah. All right. So let's, let's talk for a bit about about maybe privacy. I don't think we've, we've dug into this one yet. What are, what are some of the big privacy wins that somebody has using Firefox? And I'm trying to remember there was a there was a project that was being pushed.
I think it was at Firefox to do cookie isolation. Was that a Firefox project? What, where, where's that at as well?
Brian: Yeah. So there's a, there's a bunch of privacy features you get when you use Firefox. We had, you do get cookie isolation. There's a feature called total cookie protection that does the sort of you know, domain specific isolation of cookies and other storage. There's tracking protection features, which you can turn on either to different levels and settings, or you get by default in the private browsing mode that goes further and actually blocks or shims, even tracking scripts.
This again gets into the area of like reaching into content gets complicated area because, you know, some sites might rely on a tracking scripts call back to, to operate the page. And so we have all sorts of kind of interventions to work around that. And then we have fingerprinting protections. So fingerprinting is when.
A shared script pulls sort of identifying information off of ordinary web APIs to try to build a profile of you without relying on storage. And so that's also a, you know, feature set that, that we provide as well as, you know, the extension the extension ecosystem. Sylvester, I'm probably missing some some other things, but that's some of the highlights.
Sylvestre: One of the things that I love, which is technology, very technologically, very interesting. It's DNS over HTTPS. It's one of the cool features. So, you know, DNS is a protocol that it is very easy to spy on and your ISP is often doing it. And with DNS over HTTPS, you, everything is secure. So it's one of the cool things that your ISP cannot see where you are going.
Yeah,
Jonathan: I remember that. I remember that being a strangely controversial feature when it was, when it was first rolled out. And yeah, there was, there was some fights over that about the way, the right way to do it and who do you want to use as the end point and you know, I, I imagine some of that was that ISPs were gonna, gonna lose their way to look into what people were doing.
Sylvestre: Also to block you, right? In some country like mine you can do some blocking at the DNS level,
Jonathan: for example. Yeah, yeah. True. Alright, so I know we are, we're actually getting a little bit towards the end of our time, and I wanted to make sure and get this question, and it's one of the ones that you guys you guys included in the rundown, and that is what's, what's some of the fun stuff?
What's, what's something you're, you know, surprising or that you're particularly proud of? Something unique, a story from the history of Firefox, maybe? Let's start with Sylvester. We'll go from left to right on my radio dial.
Sylvestre: Well what I, what I love at Mozilla is I, I know that it can sound cheesy, but it's the, the expertise of the colleagues and the impact that we have on the industry.
We we We are always the underdog, as we discussed earlier. We are tiny compared to our competitors, but we still have a huge impact on the web. And what I see often and some we cannot communicate is how behind closed doors, sometimes we influence the web standards. So seeing that every day, how Mozilla is impacting the future of the web.
It's it's part of the fun of working on that project. And I see that almost every day. And as an anecdote myself, I as a kid, I the fun stuff is working on a project that I, I have seen Netscape and I think it was Mosaic when I was 13 and working on a project like 30 years later on a project that I've seen when I was a kid and you know, it was back in the day when you had one, one frame for me.
per minute seeing a guy in California surfing. And now you have a HD quality on, on the browser. It's to me, one of the fun stuff working on that project and seeing the web waiting for a while.
Jonathan: Yeah. You know, that's to, to, to take a brief detour. That's actually one of the interesting things I'm sure about this is Chromium is.
a competitor, but they're also very much, I'm sure an ally in some ways in making some of these things work. So they're, they're a, a frenemy, I suppose. It's got to be an interesting relationship.
Sylvestre: Well, we collaborate with our competitors in the standard buddies and and many times we, we collaborate with them to tell them, so look, this one is a privacy concern, but they are not going to sign up on the new feature because we have privacy concern.
With that feature, and we collaborate to make the standard better in those cases with them. So we give feedback, we make improvements, suggestions, and so on.
Jonathan: There, there was a Oh, this has been a long time ago. One of the, one of the browser teams always would like, send a cake. To the other browsers, whenever there were big releases.
Was that, was that Chrome was sending that or was that Firefox? Oh, we all do that together. We all do that. Okay. It's still happening. Yeah. One of the, one of the really fun stories I remember from that. So the browser versioning numbers have changed, right? It used to be the semantic versioning where, you know, when, when we, so for example, in Firefox, when we rolled over from three to four, that was a major change.
And then, you know, eventually got from four to five. So there would be like. 3. 0. 1. buildnumber and 3. 0. 2. buildnumber. And then, you know, it eventually has gotten to the point, I think most of the browsers are on board with this now where the, the, the major number is not nearly as important. And so now, you know, we're up to a hundred and something or 200 and something on the version numbers.
And one of the, one of the things that I found so funny there, there, there was, I think it was the Chrome team, the Chromium team, they would send a cake for The major versions and then when it was it was either edge or or I don't remember Firefox. I'll have to go I'll have to go and google this story instead of sending a cake when the versioning numbers switched It was a cupcake because it's like it's not nearly as big a deal as it was but we still want to be nice about it
Lots of lots of fun little stuff like that in there All right. So let's let's ask that same question. To To Brian, like, is there, is there a fun story or something you're particularly proud of? What's the fun stuff that you want to talk about?
Brian: Yeah, I was just thinking earlier in the conversation, I was, I was joking about the keyboard shortcut thing.
This is sort of a funny, but small thing is I was, when I started Mozilla, I was working on the developer tool. So this is the little toolbox that you use if you're a web developer debug your. Your styles and, and, and stuff on your page. Well, well, on desktop, I mentioned it, it is the a web app, basically the browser.
Jonathan: And
Brian: so we have a thing called the browser toolbox, which is the dev tools, but it's sort of popped out in a second window and it's pointing at the browser itself over sort of a remote protocol. And I had joined the team when we were kind of standing all this infrastructure up and I had to you know, come up with a keyboard shortcut for this thing.
And it took me, I was like, okay, well, you know, I think control I that's taken cause that's page info controls shift. I that's taken cause that's dev tools. I ended up landing on control alt shift. I to open the best, the best that I could do. And so but, but I guess, you know, it's been a privilege, I think, to work on the, on the web platform and on a, you know, mainstream production browser that has so many people using it, I think, especially doing it and sort of You know, I came in as a, as a web developer and getting to sort of build that platform and use it also within the browser and sort of co develop features.
You know, migrating stuff in place, some of the really old stuff, migrating it to modern standards and just sort of. I don't know. I just say the, the sort of grind, like every day, make a little bit of improvement, make it a bit faster, make it a bit better, a bit, a bit cleaner. It just sort of watching that compound, even over the time that I've been at Mozilla into the, the, the.
Quality of the product it is today is just really it's just really satisfying and to work with, with great people who are smarter than me in different areas and know there's, there's stuff so deeply, it's just been really a great a great. Yeah.
David: I have one final question as we get to wrapping this up and I promise it's not a gotcha question, but it is a personal one, and I have this platform. So several years ago, Firefox removed PWA support, or specifically the single site browser, where you can make a, Web page act like an app and that is something as a full stack developer I actually use and that's the one thing that I can't implement in firefox Is there any hope of getting that back?
Brian: Let me so the single site browser, yeah, there was like a prototype of doing that to be honest, I don't remember there was just some issues basically with it from like a like it's quite hard to You know to manage kind of the context of this is, do you carry the cookies over? Do you not? So on and so forth.
However, I will say we have started to look at at something like this again. I'll have to find you the details sort of afterwards, but I think we found, we think we found an affordance that we're maybe more happy with. And so I'll have to pull it up. I don't have it handy, but I think it's an area that that, that would be, Worth looking into I'd say it's probably hard in different platforms to do in different ways, but appreciate the The the feature request on that I think sylvester.
I don't know if you have any context on that one
Sylvestre: but we I recommend that you look into connect. media. org. It's a platform where we are receiving feedback from the user and maybe that one is already there and We'd be happy to discuss internally about those kind of things and we use that a lot like We we are not in our in an ivory tower We look at what people are writing on ICONews.
Sometimes we are crying and some, we look at Reddit and we look at connect. media. org and discourse. We, we read a lot what people have been telling us and writing about us.
Jonathan: That's gotta, it's gotta be a, it's gotta be a trip. Right on being on such a huge project that like everybody in the world knows about Like i'm i'm involved with a big project and we have you know We measure our users in the thousands Maybe a million users if we're feeling real, you know, if we're feeling real bold We'll say we might have a million users you guys are just you At least a probably a billion people recognize the name of the project right like it's just insane That's that's got to be a trip to be that big of a project.
Sylvestre: Oh, yeah. It's fascinating. It's also funny to see how people can perceive the company. And and sometimes reading some of the comments and, you know, we don't, sometimes we take the time to answer some of the comments, except when they are very snarky. And knowing how it works behind a closed door, or even behind open doors, because most of the stuff that we do is public, is is quite interesting.
Yeah. Yeah. It's fascinating at times. Yeah. So that Brian has some anecdotes also. Maybe we shortcut.
Brian: You know, I, I'm trying to, you know, I think trying to change and remove features can be really challenging in software that people this won't be a surprise to the audience, I think, but in software that's sort of widely used and people learn to rely on quirks or bugs, or just ways things work removing or changing features just gets really, you Complicated, I think, and so that's something that we, I don't know that there's like a perfect solution for that.
We try our best with sort of experimental infrastructure and communicating and things like that. But you're definitely end up sort of building on functionality. I remember removing. Some really kind of obscure air console UI. Once we built the same functionality into DevTools and just getting like roasted on on Bugzilla or some other, some other forum.
And I was just thinking these are the first time I was pretty new. And, and I just thought, Oh, I just like made a huge mistake on this. You know, I have to go and undo this. And there, and somebody was like, No, no, it's okay. Like this, this does you know, we have the functionality, we can take bug reports and we can improve any, any gaps that are missing, but it, you know, it can be a bit of a challenge.
Jonathan: Yeah. I kind of wanted to ask a follow up on that. And it's like, how do you keep your sanity? If you, if you pay attention to places like, like Reddit and you know, all of the other, all of the other places where people give feedback or talk about your project, how, how do you handle that? It's got to be a challenge sometimes, right?
Sylvestre: I can start. I am a Debian developer, so I have a good training with that. I have been contributing to Debian for like 20 years, so I have a tough skin now. So I learned, I, I'm, I'm I'm always taking feedback with a grain of salt. I know that some people wouldn't talk to me face to face the same way or in the cold.
So I'm always I have a tough skin, but, but what Brian said is we are very careful with newcomers. I had many conversations with engineers who have been reading Reddit or Hacker News, and the feedback that we receive sometimes can be very harsh, so we always work with with with the younger engineers who are not exposed to that, or who don't have a very good experience, and we are telling them, don't worry, that's fine.
If if you make a mistake, What is cool with code is that it's very easy to weave out. We can make changes. We'll ship every a major release every two, every four weeks, a dot release every two weeks. So it's not a big deal, like, at the end. Yeah. And we have plenty of CI. Yeah. So CI is very good to cast those errors.
Jonathan: Yeah, I guess, I guess with that, with dealing with feedback, maybe the, maybe the secret is to realize that the, the people that are talking to you on the internet, they're, they're not talking to you as people, they see you as just, you know, Mozilla, the, the company. And so you can't take any of that feedback personally.
Brian: Yeah. And I mean, I think it's often, you know, people are doing that because they care about the project and they care about their, their app. And so there's, there's some sort of kernel of you know, As I said, it's, it's sort of, it's a good thing to work on something that people care about. I think you do have to learn certain tactics to have the humor and thick skin and stuff to sort of navigate some of that.
But yeah, for the most part, if you look at like connected stuff, it's really funny. People are, people are you know, contributing, like it's for people, especially if somebody is not going to show up and sort of write a patch, but they have, they really care if they want this feature to work or that add on to work and they're sort of contributing.
It's a way to contribute to the project.
Jonathan: Yeah. Very good. All right. Normally at this time, I would ask you guys what we didn't cover that you wanted to, but I, I sort of feel like we have just barely scratched the surface. In fact, pretty much as soon as this call is done, I'm going to start negotiations, see if I can have you guys back because I feel like there's legitimately a lot that we did not get to, and I would like to, because it's, it's a dare and it's super interesting.
So instead I will ask you both this, and that is what what's your favorite text editor and scripting language? And again, we'll start with Sylvester.
Sylvestre: Well I am, I'm biased, I'm bash because of the coroutines, you know why? So that's why I have been contributing to the Rust implementation. And as a deleter, it really depends.
I think VS code is getting better. Better and better. I on my 20 years ago, I wouldn't have said that I was going to use a Microsoft editor, but here I am. Thank you,
Brian: Brian. Yeah, for me, I think for scripting language, it's gotta be JavaScript. That's what I've, that's my sort of go to language. I've been really.
I'm pretty excited lately with some of the new runtimes and technologies. I use the Dino runtime has sort of a really good CLI and system utilities and stuff. So if I need to turn through some files or glue some stuff together, that's my. That's my go to. And then editor. Yeah, I'll use Vim if I'm in the, if I'm in the shell, but VSCode usually for for editing code.
Jonathan: Yeah, understandable. And it's amazing how many people have basically come to that point where it's like, VSCode is just so good. It's what we're using.
Brian: I've got to, I've got to ask what about you guys on your on your answers to those questions? Maybe your audience already knows these, but
Jonathan: They might.
So, my scripting language of choice it depends very much on what I'm working on. The last few times I've had to do shell scripting, I've actually used something called Amber, which compiles down to bash code. We actually had the author on a few weeks ago in Floss Weekly. And then for text editor, my default in the command line is actually nano.
And I think that's because I actually got started on Microsoft products way back in the day and so, like, my first programming was in QBasic. And Nano is sort of familiar. It looks very much like the old Microsoft editor in the command line. So it's just where I feel at home. So those are my two.
David, what would you say?
David: I've actually never answered this question. Python is my scripting language. If I'm on the command line, remote is a server or something. It's a Vim. And my IDE of choice is JetBrains.
Jonathan: That's kind of unusual, though, for a Python developer to be a JetBrains user, isn't it?
High charm! I mean, I know it exists, I know it does, but it's just an odd combination. Alright, well, Sylvester and Brian, both, thank you so much for being here, it was an absolute pleasure. And, like I said, I feel like we very much just scratched the surface of all the things we talk about with Firefox and Mozilla.
All right. Thanks for having us. Yeah. Yeah. Glad to have you both. Okay. What what do you think,
David: David? Oh, awesome. I completely agree. And if I can swing it amongst all the wonderful co host at Floss Weekly has, I would love to come back as well. And I promise no more gotcha questions. That wasn't too bad of a gotcha question.
We've done worse on this show, but yeah, I mean, As a full stack developer having variety in the ecosystem is important. Gecko's always been a little bit of an underdog, maybe a large underdog at times. But just their support for open source for the web ecosystem, everything is just. Second to none in my personal humble opinion and just getting to talk about it is awesome.
Jonathan: Yeah, yeah, absolutely. I am, I'm actually super excited for Firefox on the, on mobile now on Android. I did not know that they had extension support there and that, that is legitimately really cool. I am really excited about that. I think, I think Firefox just became my mobile browser of choice. Which that's, that's saying something, but I think they have a convert.
So I will definitely be giving that a try. So next week on the show, we've actually got something super interesting that I am excited about, and that is the open source AI definition. We're going to have Simon and someone else from from the From OSI here. We're going to talk about that and get into all of that, which that is that is very much the cutting edge of what's going on right now with open source and AI and very much looking forward to that conversation.
Is there anything, David, that you want to plug before we let folks go?
David: Not specifically I would encourage everyone to check out the Twit Network if you don't already. We, I get to hang out with the Untitled Linux Show, the ULS guys from time to time. And there's lots of great news and tech stuff over there.
So I would say that.
Jonathan: Yeah, thank you so much for being here. I appreciate it. All right, and as far as plugs that I have, well of course there's Hackaday. We appreciate them being the home of Floss Weekly. Some fun, some fun stuff going on in the Floss Weekly world as well. Looks like we're gonna be able to get the, the old Twitter slash X account back.
And so you can follow there. That is X. com that feels weird to say x. com slash Floss Weekly. And hopefully by the time you hear this, that will be back back in our hands. Appreciate Twit working to get that back to us as well. And then, yeah, you can follow my work at Hackaday. You can follow me over at still at Twit, the Untitled Linux show.
I appreciate all those that do. And just want to say thank you to our listeners and our watchers. We appreciate it to those that get us live and on the download, and we will see you next week on Floss Weekly.