This is a transcript of What's Up With That Episode 10, a 2023 video discussion between Sharon (yangsharon@chromium.org) and Rick (rbyers@chromium.org).
The transcript was automatically generated by speech-to-text software. It may contain minor errors.
Chrome is how people access the internet and the web, so what exactly is the web platform? Is it just the internet? Today‘s special guest is Rick, who has worked on input, scrolling and was formerly the director of the Blink web platform team. Currently he’s working on transactions.
Notes:
Links:
00:00 SHARON: Hello, and welcome to What‘s Up With That, the series that demystifies all things Chrome. I’m your host, Sharon. And today, we‘re talking about the web platform. What is the web platform? Isn’t that just the internet? How does Chrome fit into that? Here to answer all that and more is today‘s special guest, Rick. He’s worked on input, scrolling, previously, he was the director of the Blink web platform team, and currently, he's working on transactions. Welcome, Rick.
00:25 RICK: Thanks.
00:25 SHARON: For the show. Cool. So let's start with, what is the web platform?
00:31 RICK: It sounds like an easy question, but actually, it‘s tough to say. I would describe the web platform as what’s in a web developers mind when they‘re writing code. What are they targeting? What’s the platform they‘re targeting? And I think we’ve had this long history, I think, as we work as Chrome engineers, we often think of, what‘s the platform we’re creating through Chrome or through Chromium. And that‘s often quite different from the platform that the web developer has in their mind as they’re writing code. It's some kind of union or intersection of all of the browsers that their users might be using.
01:01 SHARON: Right. I think platform is going to be a term that‘s going to be very overloaded in this discussion, because I think when people who are working on Chrome think about platform, they think about, oh, does this work on Mac and Windows and Linux and stuff. So that’s what platform means to them.
01:14 RICK: Native platform, yeah.
01:14 SHARON: But to people like web developers, that's not what platform means. I mean, it might be, right? There might be certain differences.
01:20 RICK: I think when you say web platform, you mean, what is the virtual operating system that a web application runs in, or a web page runs in.
01:28 SHARON: OK. And is that different from the web ecosystem?
01:35 RICK: I think so. I think when I hear the term web ecosystem, I think there‘s a lot of players in the web. So for example, say, frameworks, I would say React is part of the web ecosystem. They’re not part of the web platform, in the sense that they‘re something that runs on top of the web platform. And then maybe the way I describe web platform is it’s the thing developers are coding to. Maybe from that perspective, React is part of the web platform. But I use the term to think, like, what‘s the lowest level API surface area, the boundary between the user land of the web operating system and the kernel of the web operating system. But these frameworks, I would say, sit somewhere in the middle there. Developers might think of them as core to the platform they’re using. But we wouldn't consider them part of the web platform.
02:10 SHARON: OK. And how does that relate to the open web, which is another term we hear around?
02:17 RICK: Yeah, I‘ve heard a bunch of people complain that saying open web is redundant because the only web that exists is an open one. But sometimes it’s useful to qualify, when we‘re talking about the web, we’re talking about this consensus platform, effectively. It‘s the only major platform in history that it’s not owned by - Linux, I guess, is an open platform that‘s not owned by - well, anyway, we could debate this for a long time, probably. Most computing platforms are owned by some company that just directs their future, where the web isn’t. The web is open in the sense that anyone can build a browser. Anyone can try to convince people to use their browser. And through browsers and web standards, anyone can contribute to what the web platform is.
03:08 SHARON: OK. If that stuff seems interesting, we have an episode about open source, so check that out. This kind of thing is covered there a bit. Yeah, OK, so platform, in this case, in the past, we‘ve talked about how the browser is like an operating system because that’s what it is nowadays.
03:26 RICK: Yep.
03:26 SHARON: So I guess it makes sense, the browser runs on different platforms. But then it itself is a platform that other things now run on. And a lot...
03:32 RICK: It's like a meta platform, sometimes the term we use.
03:39 SHARON: Yeah, OK, that‘s what we’re talking about. There are lots of browsers. The internet is a big place, so I hear. How do we make sure that things just work across all the different browsers, because most people, if you‘re just using the internet, you’re like, I‘ll just open whatever my browser app is, and things just work. And that’s kind of crazy.
03:59 RICK: Yeah, it is.
03:59 SHARON: Can you tell us a bit about what goes into making all that work?
04:05 RICK: The easy, obvious answer here, of course, is standards. But actually, I think people overemphasize. I think there‘s a lot of things that go into making that work. And you think, actually, this existed to some extent before we really had web standards in the form they’re in today, right? So I would say, in some sense, competition and cloning. The web has this long history of when someone wants to make a browser, the first thing they do is they try to make something that works with existing web pages. And so they‘ll just go outright copy the behavior of other browsers. And I think that’s how the web has always evolved. And then standards are a tool to help make that easier and avoid IP legal risks in doing that. But I think it‘s important that we see standards as just one of many tools that we use to help create, the term we would use, is an interoperable web, right? A web that developers can expect that it mostly behaves consistently, regardless of where their user is coming from. But there’s lots of other tools that we use. The other one that I think is really undervalued is conformance test suites. For most of my time working on Chrome, we saw Chromium‘s test suite as our primary thing that we were passing. I mean, yeah, there was the ACID test. There were other test suites that we ran. But over the last six years or so, we’ve really gone through this transition of saying, hey, for the web platform, our first class test suite really is this web platform test suite that we share with all the other browser vendors. The idea being that passing these tests is arguably maybe even more important than standards, or at least as important as standards to creating an interoperable web.
05:36 SHARON: Standards seems like a big topic. Maybe we‘ll get into that next time. But we’ll talk about all the other stuff that goes into making the internet work for everyone approximately here. So with that, can you tell us a bit, briefly, just what part of, I guess, the internet is covered by web standards? Because in the last episode, we were talking about site isolation and how that‘s more of a browser-specific feature. It’s more of an implementation detail because how it works doesn't really matter to the web developers. So can you tell us a bit about which parts of the browser relate to web standards and which part less so?
06:14 RICK: Yeah, I think of it in terms of what‘s the contract with developers. And it’s tricky. It‘s important that there be a bit of a blurry line here, because it’s part of what enables innovation and competition in the browser space is to ensure that browsers are free to vary their behavior in ways that they think their particular users might prefer compared to other browsers. But usually you can think of it in terms of, to what extent does it impact what code a developer needs to write. So for site isolation, there are some subtle edge cases maybe, where we had to make some platform changes. When exactly does the way different tabs interact with each other? And I forget the exact details, but you can do window.open to open a tab. And you get a handle, and you can talk to that window, right? So we have to make sure all that stuff works. But then there's other nuances of that we could choose to break to make site isolation work better.
07:16 SHARON: And so you mentioned, sometimes you do make what are called breaking changes. Can you just tell us about - briefly define what that is?
7:23 RICK: Sure. Yeah, it‘s especially challenging for the web platform. It’s this very long-lived platform that‘s existed for a long time that has lots and lots of code written for it. If we insisted on making sure that all code ever written for the web continues to behave identically forever, I think we would quickly run into a place where we were stuck, where we couldn’t change the web anymore. Sometimes even making something faster exposes a bug in an application that causes it to break. And so I think it‘s important that we try to, on the one hand, we have this responsibility that a web page written 20 years ago, you might find it on the Internet Archive or it might be on a server that’s never ever going to be updated, we want almost everything that was written in the past to continue working. But we also want to make some exceptions. And this gets especially tricky as we start to say, for example, we want to improve the privacy of the web. How can we meaningfully prevent tracking cross-site if we can‘t make some breaking changes? So a breaking change just means the contract that we had with developers previously, we’re now changing that contract. There's code that was written in the past that might now function differently.
08:28 SHARON: Yeah, this is something that - I haven‘t been a web developer, despite working on Chrome. But there are changes where it’s like, oh, we can‘t do that. That’s a breaking change. And I'm like, but we can just change it, right? And then if your website breaks, to what extent is that just on the developers to stay up-to-date with this web and the platform and things that are running on versus the trade-off of making sure that the web, at large, still works as expected? Because if you have an app, you get an operating system update and it stops working, you want people to use it, you have to keep updating, keep up-to-date, right? So where is that trade-off there?
09:03 RICK: I think it‘s a really tough balance. In general, I think we’ve made mistakes in the past. Sometimes I think we‘ve had too much hubris in saying, hey, we can do what we want. I think the web’s strength is the fact that there‘s so many developers building for it, so much code written for it. The web’s strength is really this interoperability where you can write something and it can run everywhere forever effectively. So I think we have a big responsibility to keep breaking changes to the bare minimum. In practice, we have this whole process that we go through called - we have this process on our blink-dev mailing list, where if you want to propose a change to the web platform, you have to go through this public process where the trade-offs of that change can be debated. And specifically, for breaking changes, we have a set of things that we ask people to look at. And there‘s a doc, you can see it at bit.ly/blink-compat I wrote this doc years ago. And it was the guidelines that the API owners like myself and others would use to try to evaluate whether the benefits of a change seemed to outweigh the risks, or how do we quantify the risks of this breaking change. The simple example that people like to point to all the time is the UseCounter. What fraction of page loads use thing? At the very extreme, we’ve had a few cases where somebody wanted to delete an API, and we‘ve gone, whoo, that sounds scary. What are you going to break? And we’ve checked our anonymized data from the field, and we found this API has never been called, more or less, basically, it‘s literally like never, or maybe there was a couple people loading a test page or something. And it’s like, well, yeah, we should just change that. Why should we feel constrained by that? But it‘s overly simplistic to say, oh, if your page is used on more than 0.0001% of page loads, then you can’t change it. It‘s a lot more complicated than that. But there’s a lot of different signals we try to look at. But at the end of the day, the real test is let's try making this change and see what happens. And if it causes - if our data suggests it is going to be low risk and then we try it and we put it in Canary and Beta and we get reports that things are breaking, then we got to stop and we got to rethink.
11:11 SHARON: Yeah, I guess a lot of the difficulty of this comes from the internet being just a very fat-tailed place. And that's part of the risk. Yeah, so in terms...
11:19 RICK: There‘s also a very big difference in degree in different types of breakage. Sometimes you make a change and sites just stop working entirely. And that’s a much greater risk. We‘ve got to be a lot more careful with that. Sometimes we can design things where the severity of breakage is a lot more moderate. Maybe we’ve got a security hole in a particular case - there‘s one that we’ve been looking at recently where SVG images embedded in a certain way where they‘re using the spritesheet in a way that, first of all, is really bad for performance, but second of all, it leads to a security risk. And we found a few sites that are relying on this pattern. And when we fix it to have Chrome behave the same as WebKit, we see sometimes an icon doesn’t show up. And it‘s, like, well, OK, that severity of breakage, that’s not good. We don‘t want to make icon stop showing up. But the trade-off of get this performance and security win, we think, even though that might be on a higher fraction of pages than we would be comfortable saying is trivial, that’s something where we say, well, actually, that one might be OK, because it doesn't really break the functionality of web pages as far as we can tell.
12:30 SHARON: OK. Yeah, everything is just a trade-off, right?
12:30 RICK: Yeah, exactly. All sorts of trade-offs.
12:35 SHARON: Yeah. So with all these changes, who out here is wanting these changes?
12:40 RICK: So it varies a lot. The easiest example to defend, I think, is privacy, right? Removing third-party cookies, that is a huge breaking change. And it's debatable.
12:46 SHARON: You can turn that on yourself, if you go into the settings and stuff, if you want to.
12:52 RICK: Yep. Yeah, absolutely. Yeah.
12:52 SHARON: It's in bug reports.
12:52 RICK: Yep. So in that case, I would say, that‘s really driven by our users. Our users want to use a web that involves less tracking. And so we’re going to accept some breaking changes with a whole lot of different mitigations to try to minimize the cost. In that particular case, we have a user opt out where users can - we warn people and say, oh, you just reloaded this web page. Maybe it‘s broken because of third-party cookies. Do you want to click here to turn third-party cookies back on for this web page only, for example. So those are the kind of mitigations we can put in place. You can think of this too. If you’ve ever seen the pop-up blocker, this is one of the web‘s first non-trivial breaking changes is the web used to be allowed to open as many new windows as you wanted. And at some point, people realized, oh, we probably shouldn’t let any web page open 10,000 windows.
13:36 SHARON: Right.
13:36 RICK: So maybe we should limit it to one window per click. But that was a breaking change. And so we introduced a pop-up blocker UI that could say, hey, this website is trying to open a pop-ups without you clicking, asking for a pop-up with a user gesture, would you like to allow it?
13:49 SHARON: This is one of those things that if you do it well, people don‘t notice, because I remember, somewhat, the pop-ups and all being a whole thing. And it’s like, oh yeah, they just stopped being a problem one day. Cool.
13:59 RICK: Yeah, except when you're doing some company internal training and the first step in the training is turn off your pop-up blocker.
14:05 SHARON: Yeah. Yeah, well, what can you do? So the users here is a group who wants changes. What are other groups and entities that are wanting changes in functions and directions in the web?
14:22 RICK: So another really good one that‘s come up a lot is in the sake of interoperability. We’ve had some - sometimes, it‘s just, hey, we’ve got this bug, and some website‘s depending on it. One I was involved with is Gmail was depending on - I think we were parsing the CSS border-image property in a way that was defined in a draft spec that was never the official spec or something like that. And Gmail came to rely on this. And so there’s not some user saying that they want this to behave better, but Firefox was conforming to the spec. And so we have to have this whole debate, well, this isn‘t good long-term. This is an interoperability problem on the web. Do we need to update the spec to say what Chrome is currently implemented should be supported everywhere? And we went - sometimes that’s the right thing to do. But we went through discussing with Mozilla folks and other folks in the CSS working group, and we said, no, really that‘s just a bad design. And if it wasn’t for a few sites depending on it, we would just do the right. So in that particular case, the big question at the time was, is it just Gmail? How many other sites are there? And this is before we had the ability to do site specific telemetry. We just landed a bit of a hack into Chromium to say, any time you see this weird border-image thing being used, check to see if you‘re on Gmail. And if you’re not on Gmail, report a metric to say how often it‘s hit. And what we found was there was very few sites other than Gmail that was relying on this quirk. So we said, OK, we’re not going to let Gmail hold back interoperability of the web. We‘re going to make this breaking change. And at the time, Gmail didn’t want us to change it. It was a legacy Gmail product. It was their mobile product. They didn‘t have anybody working on it. But at the end of the day, it was the web standards community saying, this is how browsers should behave. And it’s not reasonable to ask Firefox to go implement this hack, implement a bug, basically, for some website to work. So all browser vendors just agreed that we're going to support the spec here. And then once we did, once that was in Canary, we talked to the Gmail team, and they grudgingly agreed to go fix Gmail to rely on the spec behavior.
16:15 SHARON: Classic Gmail.
16:15 RICK: Yeah.
16:21 SHARON: So the spec, which spec is that? There's only one spec?
16:21 RICK: No, so this one was for border-image. But yes, this is the problem. I mean, sometimes - hopefully, in the best case scenario, every web platform feature has one spec somewhere, or at least a spec - usually a spec will have different versions, effectively. So in this case, it was CSS border-image. I forget which CSS spec it was in. But yeah, there would be a spec somewhere defining this as a semantics for border-image. But then it gets tricky, because sometimes, if you Google border-image spec, you might get a link to the W3C recommendation, which might be what the spec was, basically, four years ago. And there might be an editor‘s draft today that is different. And so one of the philosophies we have in Chromium that’s a little controversial around this is that we really believe in a living web, living standards, the idea that the web is always evolving. And so we generally just use whatever the current editor‘s draft is of any spec. So it’s usually not the first search result you will get for a spec. You often have to go and click on the editor‘s draft to see, oh, this is the version of the spec that we’re trying to support in Chrome.
17:26 SHARON: OK. And who out here is responsible for these specs?
17:34 RICK: A lot of the times - I always say that feature teams working in Chromium, working on API features should feel like they have some responsibility over the spec, making sure that the spec and their implementation are consistent. And if you think the spec is wrong, it‘s your responsibility to go and start a conversation. But any spec, there’s usually some group. Eventually, we want to get - I should clarify. A spec is just a definition of how an API should behave. And usually our intent with every spec is that it be on a standards track to become a standard. And a standard is a spec that‘s blessed by a standards development organization to be something that has multiple implementations conforming to it and has reached a level of maturity to say this should be considered a standard. The distinction there sounds a little academic. But it’s important to know, we ship things in Chromium all the time based on specs that aren‘t yet standards. But we have an Intent to - our whole Blink process and the Intent to Ship email threads that we do are all about trying to ensure that the platform that we’re creating in Chromium is moving towards a standardized one, is expected to become interoperable over time. And there‘s delicate balance to walk there because we don’t want to slow the pace of evolution of the web. And we always say, Chromium‘s velocity can’t be blocked by others. We don‘t want to say that anybody in the web standards community can say, no, this can’t go into Chromium, because that's really important to competition between browsers, that browsers can ship what they think is right for their users. But at the same time, we want to trend towards a web that is interoperable and standardized.
19:17 SHARON: Right. Yeah, it seems like a balance there, because on one hand, you want a website to load on all these different browsers. But if they all are just implementing the spec, then what makes them different? And why pick one over the other?
19:29 RICK: Yep. Yeah, there's definitely a balance.
19:34 SHARON: In terms of the different organizations responsible for the specs, is there one organization with multiple divisions, I guess, branches? Or are there different organizations that are responsible for different areas?
19:46 RICK: Yeah, there‘s lots of different organizations. So we call it the SDOs, Standards Development Organizations. So we work a lot with the W3C. People are probably familiar with the W3C. People are maybe less familiar with a lot of the web’s core functionality, so HTML and DOM, core things of the web have not been really driven by the W3C for a long time. There‘s a fascinating history. Chris Wilson could probably tell you more about this if you interview him at some point. But at some point, the W3C decided the web was for documents. And a group of browsers got together and said, we really want to make web apps. And the W3C said, the web is not for apps. And so they created a different SDO called WHATWG, the Web Hypertext Application - blah, blah, blah - Working Group, and basically, had to write a new HTML spec from scratch. And then that really became what all the browsers pointed at as the HTML. But for a while there, we had two different specs that were both labeled HTML. And people assumed that W3C HTML was what the web implemented, where, in fact, every single browser really implemented WHATWG HTML. And there was politics involved and all of that. But due to some great work by Shruthi and others, we got that worked out now. So now WHATWG and W3C collaborate, but still, HTML and DOM are really done in WHATWG. The JavaScript language is done in a different standards group called ECMA. Yeah, the IETF, like, lower level networking stuff, there’s the IETF group. And yeah, there‘s a bunch of different standard groups. And even within W3C, there’s different levels of maturity. There are working groups that produce these standard track documents. That‘s great for stuff that’s fairly mature. But when you want to start exploring and trying to explore a new area and do something that‘s cheap to fail, that overhead doesn’t really work. And so things start in community groups, which are much lighter weight process. So a lot of the new APIs that we do start in a group called the Web Incubator Community Group in the W3C. And the idea is that you can start with a small group of folks who are interested. And it‘s really, whoever is interested in trying to solve a problem can get together in this forum, and really, it’s just about collaborating on GitHub trying to work together toward something that might eventually become a spec that could be on the standards track in a working group somewhere.
12:03 SHARON: And who are the people typically working in these organizations? Are they people who have day jobs working on a browser or other open source projects or what kind of things?
22:16 RICK: This is one of the things I love about working on the web. It‘s a wide variety, even more so than you’d see if you look at who‘s contributing to Chromium, right? There’s people who contribute to Chromium just as a hobby in their free time. But it‘s mostly Google employees and employees of Microsoft and stuff like that. But in the standards world, I find there’s a lot more independence. There‘s a lot more - there’s people who will - contribution can be everything from chiming in on a few GitHub issues to being an editor of the specification. So the investment can vary quite a lot. But yeah, so, certainly, browser vendors invest a lot. A lot of spec work is done by browser vendors. But then also, the people using those APIs - so sometimes somebody will have a particular need for an API in their product, and they‘ll care enough about it to go and invest in either doing the standards work themselves or hiring an external consultant to go and do that standards work. My favorite example of that, if you’ve ever used CSS Grid, a lot of that work for Grid - I mean, I think a lot of the standards work was done by Microsoft initially. And I‘m sure there’s other browser folks involved. But at the end of the day, Bloomberg, the financial company, they have these Bloomberg terminals, right? They run an application that‘s just running inside of Chromium. And it’s not really running on the web. It‘s just running inside of Chromium. But they’re the ones who hired Igalia, which is a consultants company to go and implement this grid feature in Chromium and WebKit, I believe.
23:47 SHARON: Can you tell us a bit more about Igalia? Because if you look at changes - if you just look at the blame in Chromium code search, you see Igalia emails come up a lot. So who are they?
24:00 RICK: Igalia is the number one contributor to Chromium outside of Google.
24:00 SHARON: OK.
24:05 RICK: And they‘re a collective, which means they’re a group of folks. So they‘re not a company, but you can think of them as an independent consultancy agency, basically, that are web browser or open source experts. They don’t just do web, they do other stuff as well. But they‘re really open source experts for hire. And so, yeah, it’s really cool. It means that any some company thinks, oh, I really wish the web was better in this way, but I don‘t know how to make that happen. They can just go hire Igalia. And there’s others there‘s some other companies like Bocoup. And there’s a few other consulting companies. But Igalia is the one that's really biggest into contributing directly to browser engines.
24:43 SHARON: Oh, neat. OK.
24:43 RICK: And Google, ourselves, sometimes we find it makes a lot of sense for us to just hire Igalia to do some work.
24:48 SHARON: Right, like the Mojo legacy IPC transition.
24:55 RICK: Yeah, some of our code health stuff, we've found it to be most effective to hire a guy to help us with some of it.
25:00 SHARON: OK, cool. I didn't know that.
25:00 RICK: Yeah.
25:00 SHARON: Neat. With the open source versus proprietary - I don't know, company browsers, how does Chrome versus Chromium fit into this whole web platform as a whole?
25:12 RICK: So in general, we want the platform to be consistent across browsers. So, I mean, Chrome and Chromium are already almost identical in a bunch of ways, in most ways. There are places where Chrome adds, and actually, I guess you could even argue, Chrome does add some things to the platform. So media codecs, for example, is H.264 is a video codec that requires a license. And so Chromium doesn‘t come with an H.264 decoder because you’ve got to get a license to have that. Whereas, Google Chrome pays the license fee in order to be able to ship an H.264 decoder. So in that sense, that is really an aspect of the platform. You have a web page that plays H.264 videos. That is a web page that will work in Google Chrome and not Chromium. But that‘s an exception. We don’t like that. In general, we would try to avoid ever getting that situation ever again. But otherwise, from a platform perspective, you can expect them to really be identical.
26:10 SHARON: OK. With Chrome, and probably to a lesser extent, Chromium, but not really, there‘s a lot of people who use this browser. So how do people who work on Chrome try to maintain an open web and have everybody have a say in things, when if Chrome just went ahead and made a change, it would force other browsers to do a similar thing. And generally, we don’t want that. So how do we balance that?
26:40 RICK: Yeah, there‘s a tricky balance. Like I said, ultimately, at the end of the day, Google feels accountable to our users to build the web that we think our users want. But we also feel accountable to the web industry, the ecosystem, to have an interoperable and standards-based web. And so one thing we try to do is we have this the Blink launch process I mentioned earlier, where a key part of that process is we want to make sure that any time we want to make a change to the web platform in Chromium, that change needs to be described in a way that others could implement, so that means a specification. And critically, it means a specification that has IP rights, that other people could implement it in a way that they’re not likely to get sued for patent infringement for. But also, we want to have a public debate of the trade-offs, the maturity level of this, is this API well enough justified, is the specification a high enough quality. Any time we‘re shipping a new API, we also want to make sure that we have solicited feedback from others. So we generally will file standards positions. Both WebKit and Gecko, the Firefox engine, have a process for us to file a request for standards position to ask, hey, what’s your opinion of this. And just because they don‘t like it doesn’t mean we won‘t ship it. But we have a group of us called API owners, who, anytime somebody wants to ship a new API, we review these criteria - which, by the way, if you go to chromestatus.com, you can see each of the features we’re shipping. And you can see all the fields that people have to fill in, in order to request permission to ship a new API. And then the API owners review those and make a judgment call on whether the benefit of shipping this outweighs the cost or the risk that this won't be an interoperable behavior across browsers.
28:26 SHARON: OK, yeah. I feel like it‘s the kind of thing where the more you hear about it, the more you’re just like, how does any of this work?
28:32 RICK: Yeah, it‘s kind of incredible. It feels like a lot of process overhead sometimes. And I really feel - we try to make it as lightweight as possible. We try to make it also - we want it to be an environment where it’s OK to make - if you‘re posting to this mailing list that lots of people watch, and it’s OK to make mistakes there. I‘ve made a bunch of mistakes in some of my engagement on some of this stuff in public. So it can be a little nerve wracking sometimes working in public. I know Elly talked about that a little bit in open source as well. Yeah, but it’s incredible at the end of the day, we do end up with a web that mostly works the same across browsers. In fact, I would argue, if you look at the whole history of the web, I would say that the web is probably more interoperable today than - I mean, it used to be that it was common for websites to say best viewed in. Best viewed in Netscape Navigator 4, right? And that was - it took a lot more heroics, I would say, back in the day to make a website that worked consistently across browsers, where now we have much more of a culture of each of the browser engines, generally, typically, prefers to ship only when there‘s a good quality spec and plausible interoperability between engines. But that’s still relatively new when you think about it in terms of the whole history of the web.
29:54 SHARON: With the point of the web being more interoperable than before, now with things being, like, you see Chromium based things in the most random places, right? Cars, that space thing...
30:11 RICK: Yeah, SpaceX.
30:11 SHARON: Right. All sorts of devices, embedded systems, and all that kind of stuff. So how has that kind of thing - more things becoming internet enabled and connected - I was trying to buy a washer, and only one model was not internet connected. I was like, I don't need this. But anyway.
30:31 RICK: I have a blender that runs a version of WebKit maintained by Igalia.
30:38 SHARON: Yeah.
30:38 RICK: It's pretty cool, because it has a screen that you can pull up recipes on, stuff like that.
30:44 SHARON: OK. Yeah, so now that all these other things are now computers, that not that long ago, only computers were computers, how has that affected the web platform? Because a lot of times, in - so my mom works in navigation, which affects a lot of this stuff. And sometimes you'll hear things like, why is this using Chromium? So how has the craziness increase of the uses of Chromium, how has that affected the web platform?
31:11 RICK: Yeah, it‘s interesting. We created Chromium to be a great web browser. And we’ve often been faced with this struggle, we wanted Chromium to be open source. We wanted people to get whatever benefit from it that they could. We wanted them to use it for other reasons. But we've also found it to be important to really stick to the principles, what is Chromium for? And so we say, Chromium is intended to be a web browser. And people use Chromium in other environments, like, you can use Electron as an application platform. You can build Slack or VS Code or whatever. I think Darin talked about this a bunch in his...
31:52 SHARON: You watch the videos. Wow.
31:52 RICK: Of course I did. [LAUGHTER] But I think that‘s awesome. But it’s dangerous, I think, to think that, hey, we should just make Chromium. Chromium should be a project that should be an operating system for everything. And so instead, what we‘ve sometimes found ourselves saying is, hey, you’re using this for a fork of the web, therefore, you should use a fork of Chromium. So I mean, even e-readers, some e-readers like EPUB format is CSS with some bespoke additional things in it that aren't available in web browsers.
32:25 SHARON: Right.
32:25 RICK: And so we‘ve said, hey - at least, it was at some point. I don’t know the current state. Maybe this has changed. There‘s TVs that have web browsers built into them. And then they have some non-web extensions to the web platform for their TV platform. And so in all those cases, our principle is, hey, it would make it - it would be an unreasonable maintenance burden on Chromium to support all of these different use cases. Think of your CQ. We’ve got enough bots on the CQ already, right? If we had to have bots for all these different...
32:55 SHARON: TV, fridge, blender.
33:01 RICK: Yeah, exactly, from every different manufacturer, every different version, right?
33:01 SHARON: Yeah.
33:01 RICK: So we think it‘s great if people want to use Chromium for other use cases than what it is intended, which is building browsers. But that’s not a cost we're willing to then impose back on the upstream repository.
33:14 SHARON: Right. Yeah, I guess that‘s another trade-off too, of just simplicity and hand-in-hand security versus features, because just from what I see, there’s so many cases where it‘s like, oh, we needed this. And there’s just all these edge cases. And it‘s very hard to reason about. And you pay for that, in terms of security and just how long it takes to figure out what to do, what you’re doing.
33:41 RICK: Yeah. And we saw this. I mean, this is a trade-off that I think any open source project needs to make. It‘s reach versus complexity or something. And I remember back when Chromium was using WebKit as our browser engine, WebKit did support a variety of different use cases that Chromium didn’t support. And it did, for example, there were - I forget the number - there was five or six different build systems that you could use to build WebKit. And so when you added a file, you had to go and update five or six different build rules, right? We take it for granted now that you just have to update one GN file. But for those of us that worked in the WebKit days, and I‘m guessing maybe it’s somewhat better now. But I‘m sure there’s still an aspect of that. And it‘s a trade-off, right? There’s a benefit of, you can get broader reach if you‘re willing to support a wider variety of configurations. What toolchains do you use? We’ve taken a pretty hard hardline stance on Chromium supports Clang. And Igalia‘s heroics notwithstanding, they do a lot of work to make sure that GCC can still work. But officially, Chromium just supports Clang because it’s already so complicated to reason about all of our different dependencies, that we want to take every opportunity we can to say, hey, the core of the project, we're just going to pay these costs and try to avoid these multiplicative matrices of test environments.
34:57 SHARON: Yeah. Yeah, I think, looking at things now and learning about how things are now, it‘s like, oh, everything is so hard. But then you hear about stuff like this, you’re like, oh, things used to be so much worse.
35:02 RICK: Yeah, and that was - I mean, another aspect of the complexity here is where do you define your repository boundaries? Chromium is a self-contained, well, it‘s not self-contained. Chromium is designed to be a browser, pulls in a bunch of third-party dependencies. So, for example, V8, our JavaScript Engine, comes from a different repository. But the Chromium UI and the web platform Blink sit in one repository today. It used to be, obviously, when we were using WebKit, that was a different repository. Apple owned the WebKit repository. We would pull it into Chromium. But then it would mean, those of us who work back in that day, a lot of changes you wanted to make, you had to do these three-sided patches, where it’s like, oh, you‘re going to want to use something in - let’s see, how did this work? Man, this was a long time ago. You had to add some code to Chromium, some scaffolding for some APIs that WebKit might call into. And then you‘d go and you’d land the WebKit patch that could call into those Chromium APIs. And then you had to go land the Chromium patch that would call into the WebKit API. So it was pretty common that one feature that would be one commit for us today would be three separate commits in the old days. And if you want to make a breaking change, man, that‘s even harder. You’re trying to change the protocol between WebKit and Chromium, you‘ve got to basically add a new version of the API into Chromium first, and then update in one commit. And then your next commit, you have WebKit call into that new one. And then your third commit could go remove the old one. And it was just - there’s a trade-off there. It's more generality, but a lot more complexity.
36:28 SHARON: Oh, my goodness. [LAUGHTER] Right, so now that we have reduced some of that complexity in that way, it's like, if you have a bigger spaces, you fill it with stuff, right?
36:40 RICK: Yeah, that's true.
36:45 SHARON: Now that difficulty has been taken away, what difficulty has moved in to replace it?
36:45 RICK: I mean, we‘ve just added a lot of code, a lot of complexity. The web platform’s gotten a lot more complicated. Again, this is a trade-off that people would debate. As we‘ve gone to try to meet more and more use cases on the web, we’ve made the web platform more complicated. We‘ve added more APIs that can do different things. You could argue, should I be able to build a website that controls my LEGO robot over Bluetooth, or maybe you could just say, that’s not a use case we care about on the web. This is something we actively debate, we disagree with other browsers on. On Chrome, partly, we take the security philosophy of saying, well, we would rather our users are using an API that could have some abuse risk than installing a native application that almost certainly is riskier.
37:33 SHARON: Right.
37:33 RICK: So again, there‘s a trade-off to be struck. But the complexity cost, the burden that we’re creating on the whole web platform by having all this complexity in the long run, is it actually paying for itself? Reasonable people will disagree on that.
37:47 SHARON: This is more of just a miscellaneous curiosity question. But in terms of the people debating these kinds of things, who are actively working on standards and all that kind of stuff, do you have an idea of ballpark how many people across various organizations and individuals...
38:05 RICK: That's a good question.
38:05 SHARON: Are doing it? Because when I first joined Chromium and stuff, a lot of people work on Chrome. But it‘s not as many people as you would think for how widely used it is. Anytime you’re using the internet, Chrome is in there somewhere, probably, like Chromium. And for that amount of use, it‘s like, oh, there’s not a ton of people working on this.
38:24 RICK: I would say, if you just say for the web, what‘s the set of folks who are working on trying to evolve the web platform, the web standards community. And I assume we’d probably go all the way down to HTTP. And it depends a lot where you draw the line.
38:36 SHARON: Right.
38:36 RICK: Because there‘s a ton of people, for example, in the identity community that talk about different standards for identity that browsers don’t necessarily understand. It‘s built on top of the web. So if we exclude all that and we just say, like, number of people involved in trying to evolve the specifications that make up the web platform, my guess would be somewhere on the order of probably less than 10,000. It’s probably more than a couple thousand. But yeah, that'd be my guess.
39:07 SHARON: Yeah. Because that‘s somehow both more and less than I expected. I don’t know what I expected.
39:13 RICK: Yeah, I mean, that might be an overestimate. I mean, you go to a conference, like, W3C TPAC is W3C is annual conference. And I think - I don‘t know the numbers off the top of my head. But I think there’s often a couple hundred people there.
39:19 SHARON: OK.
39:25 RICK: Right. So those are probably the most - and including virtual attendees, I think it's 200 or 300 or something like that. Anyway, I probably should know those numbers off the top of my head.
39:31 SHARON: I don‘t think - that doesn’t seem like that useful information to have.
39:37 RICK: I think it‘s a really good - it’s a really interesting question. If you think of the web as this organic ecosystem, like, we‘re talking about web ecosystem. So you can think of - and it’s almost like this living, breathing entity that changes over time. Some basic questions like, well, how big is it? How many people are contributing to it? How much money is going into evolving the web ecosystem? For the most part, we just don‘t know. And also, then you could ask, well, is that good or bad? Does society as a whole benefit when more money goes into making the web better? Or actually, would society benefit more if there was this is a more stability and there was more constraint and the web was changing less? There’s really hard questions. And I think it‘s just like we see with climate or any question about natural ecosystems, it’s a very complex system that's just incredibly hard to reason about. Oftentimes, the best you can do is be scientific and go do a study. Change something and see the reaction.
40:34 SHARON: Right. Yeah, I mean, it‘s very crazy to think about because a lot of the web is available just for free. And you’re not paying for it, but it all works. There‘s a lot of work that goes into it and keeping it running. So what’s going on there?
40:52 RICK: It‘s really fascinating to think about the economics of this. For every platform, what’s the economics that led to this platform existing? And early computing, it was really about device sales. You would buy an IBM mainframe or something, and the cost of buying that mainframe would go to build the operating system, I‘m assuming. I didn’t use computers back then. But certainly, like, Windows, Windows was funded by - you buy a PC, and you pay for a Windows license. So you‘re really buying the operating system. Where does the money come from for building browsers? The reality today is that there’s multiple reasons why companies might want to build browsers. At Google, one of the reasons we invest in browsers is because we want to make sure that Google services can have a platform that they can run on, a stable platform for you to be able to use Gmail or whatever. But, of course, search engines are a big part of that as well. A lot of browsers are funded by search engines, at the end of the day.
41:52 SHARON: Yeah. That makes sense. Anyway, that‘s very complicated. That is not my day job, at least. So we will not talk about things we don’t know about. Yeah. We have a bit of time left. Do you have any just general fun stories about web platform things and the time you've worked on it? Hot takes, we like those.
42:09 RICK: Yeah, what was the one I was telling you I was going to tell you about?
42:14 SHARON: Oh.
42:14 RICK: I forgot now.
42:14 SHARON: OK. Something about a breaking change?
42:19 RICK: Yeah, I don't know.
42:19 SHARON: OK.
42:19 RICK: I mean, one of my fun - just going back to this question. We were talking earlier about compatibility. And it‘s interesting to me, whenever a new browser gets started, it’s always a big challenge to go make it work with the existing web. And once a browser becomes popular, then somehow it becomes less of a challenge. It‘s like, oh, developers are going to do the work now to make sure that it works in this browser. And so it was, I think six or seven years ago or something, and I was doing some work for Gmail. And I was seeing how hard it was to make Gmail work reliably across websites. And we’re also talking with, I think this was the time when Microsoft decided to build their Edge HTML browser engine. They were basically building a new browser engine from scratch and trying to make it be compatible for the web. And we realized, man, a lot of our ideals about, hey, the web is standards-based and whatnot, like, it was falling down in practice, right? The web was actually - Edge HTML was having to basically reverse engineer a lot of things and put a bunch of behavior into their engine that wasn‘t in any spec anywhere. And we realized, holy crap, this is actually a really big problem. We realized that we really weren’t taking this idea of conformance testing as a first class property of the web. If we‘re trying to design the web to be a coherent platform, it’s like software engineering 101 to say, if you want a reliable platform, that platform needs to have a test suite. And we really didn‘t have a test suite for the web back then. Things like web platform tests existed back then. But we weren’t treating it as a first class part of our engineering process. And so we had this dream back then to say, we need to put this as a first class part of our engineering process such that whenever we change the web, we‘re always making sure that we are contributing to this test suite. We imagined a future where any time anything ever went into the web, it was always getting added to this test suite so that conforming to this test suite was your test whether or not your browser could actually run the web. Anyway, I bring this up just because, to me, it’s mind-blowing to realize, back then, that seemed like such an impossible task. And I‘d say, now, we’ve really crossed this threshold where all the browsers now see conformance test suites, web platform tests, and some of the other projects have their own test suites, as a first class part of the engineering, the way we engineer the web. So I would say we‘ve really up-leveled the engineering of the web to be more disciplined. And I think everyone who’s worked on the web platform over the last 5, 10 years should feel proud of how it's now engineered more like a real - not, congratulations, we have a test suite.
44:49 SHARON: So for engineers who work on Chrome or other browsers, for a lot of them, they don't really ever interact with the open web part of it, right? So even in navigation, which seems like it affects a lot of stuff, very rarely does it intersect with open web facing stuff.
45:08 RICK: If you‘re lucky. I don’t know about you, usually it intersects accidentally, right? I don‘t know about you, but every time I’ve had an intern or a Noogler, and we said, oh, this would be a good starter bug. And it‘s turned out, it’s like, oh, this is going to be a one week bug as your starter bug. And it‘s turned out, oh, it turns out when they went to fix it, some weird web page somewhere broke. And it turned into a six month project of understanding the compatibility constraints and trying to find a way to do it in a way that doesn’t break websites.
45:32 SHARON: OK, yeah, that is my everyday life. Not necessarily always for - more importantly, I guess, even for where I am, having a solid understanding of how the web platform works is not strictly necessary for getting a lot of things done. For some things, it is. So for people who don't really interact with the more open web standards, that side of things, what do you think they should know about the open web for just being someone who works on a browser?
46:03 RICK: That‘s a good question. Certainly, there’s a line of thought that anybody working on a browser should try being a web developer. Try building just a little hobby website. But I don‘t know if that’s - I think there‘s some benefit to that. When I started on Chrome, I said, how am I going to work on Chrome? I haven’t built for the web - I think the line I used, I did some work for a website development company back in the mid ‘90s. So I was like, hey, last time I built for the web, tables were new. So I went to work - that’s why I was working on Gmail for a little while. I was trying to get myself experience in what it‘s actually like. And actually, that served me really well. That helped me see that we were missing this big problem with interoperability. But I don’t think it‘s necessarily for everyone. I think it’s very reasonable to say that you don‘t need to be an expert. Being a web developer and being a browser engineer are very different jobs. And I don’t consider myself an expert web developer at all. And so, I think, in general, it is totally fine to be an expert in browser navigation, for example, without being an expert in web development. It might get harder - depending maybe if you‘re lower in the stack, it’s probably easier. For example, if you work on the layout system or the style system, you probably need to at least have some understanding of web design and how you would use the style system to make UI in different ways.
47:32 SHARON: Yeah, because I think, since working with a bunch of security folks, a lot of them do have compatibility-based aspects to their job of just, how do we make the HTTP headers, for example, kind of thing. And then, like, oh, I don't know how any of this works, OK.
47:58 RICK: I mean, one thing I‘ll say is anytime - I found it useful for me, working on browsers for - it’s been 13 years now, I guess - is when I‘ve worked on a problem, I very often start on MDN. And I say, oh, here’s a bug that somebody‘s filed. What is this web platform API that they’re using? And I‘ve often gone back and forth between MDN, Mozilla Developer Network, is the API reference docs for the web. And it’s pretty darn good. It does a good job of explaining. I would never start with a spec, even for somebody that‘s - the specs go into the minutia detail. They’re not intended for web developers. They're intended for browser engineers. So I usually go back and forth between MDN and then a simple editor like JSBin or something, where you can just take a chunk of HTML and CSS and JavaScript and just paste it over here and just hack on changing it. And I always find that to be the best way to learn.
48:44 SHARON: OK. All right, well, go and make some websites, guys. Yeah. All right, well, that was cool. Yeah, it‘s very neat to hear about how Chrome fits in with the web at large, because if you’re working on a browser, it‘s like, OK, this is my project, my job, whatever. And if you don’t interact with the rest of - if you‘re not in one of these other - working on a thing that is open web facing, it’s easy to forget about all of that. Like, oh yeah, this is part of the internet.
49:20 RICK: I think it‘s really easy to get focused on your area of expertise. And I think it’s helpful to take a step back every now and again and look at the 10,000 foot view and realize, hey, collectively together, we‘re building this unique thing, this open computing platform that is, by far, the world’s dominant computing platform. There‘s more web developers than developers of any other platform, I think, by an order of magnitude or something like that. And it’s this crazy, messy, chaotic thing. It‘s like Wikipedia in a way, right? Most people would assume, it couldn’t possibly work. But actually, when we get the incentives aligned right, it actually seems to work over time. And we‘re actually making this open platform that gets more and more powerful over time. It’s pretty cool.
50:04 SHARON: Yeah, the topics I‘ve been trying to cover so far have been like, these seem like very important things. And I feel like - it’s like, oh, I should know about this. I don't, but I should. And this is another very good step along that journey. Thank you very much for sitting down, talking.
50:18 RICK: Thank you, it was fun.
50:18 SHARON: Yeah, have a good day.
50:24 RICK: Thanks, you too.
50:24 SHARON: There are two in person, and they‘re both - they’re clearly a work in progress.
