docs/transcripts/wuwt-e10-web-platform.md

# What’s Up With Web Platform

This is a transcript of [What's Up With
That](https://www.youtube.com/playlist?list=PL9ioqAuyl6ULIdZQys3fwRxi3G3ns39Hq)
Episode 10, a 2023 video discussion between [Sharon (yangsharon@chromium.org)
and Rick (rbyers@chromium.org)](https://www.youtube.com/watch?v=zFwSAMMCYxI).

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:

- https://docs.google.com/document/d/17jLBCyXFkbHCk81JayoRe93dkO3X4GncvIlLfDAD1WU/edit

Links:

- [What's Up With Mojo]
- [What's Up With Open Source]
- [What's Up With Processes]
- [What's Up With Site Isolation]
- [bit.ly/blink-compat]

---

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.

[What's Up With Mojo]: https://www.youtube.com/watch?v=at_35qCGJPQ
[What's Up With Open Source]: https://www.youtube.com/watch?v=zOr64ee7FV4
[What's Up With Processes]: https://www.youtube.com/watch?v=Qfy6T6KIWkI
[What's Up With Site Isolation]: https://www.youtube.com/watch?v=OH-bt7spDgo
[bit.ly/blink-compat]: https://bit.ly/blink-compat
[chromestatus.com]: https://chromestatus.com/