Warren (00:01)
Hello, everyone, and welcome back to another episode of Adventures in DevOps. And I'm Warren, and here today I have senior staff engineer at Google working on Chrome, who leads the Federated Credential Management, FCM project, originally from Brazil, I think, and at Google for almost 20 years, Sam Goto. Thanks for joining us today.

Sam Goto (00:24)
Hi, nice meeting you. Yeah, thanks for having me. So excited to be here.

Warren (00:27)
Yeah, I think every engineer or anyone who's in the technical domain probably always has the same question for you, which is your last name. That must break some systems.

Sam Goto (00:38)
you'd be surprised how many systems I broke at Google. Yes, I am actually Sam Gotu. Gotu is my last name. It's technically a very popular last name in Japan, ⁓ although I've been ⁓ born and raised in Brazil, which surprised a lot of people too. But I am Gotu at Google.com. I am Gotu at Chrome.org. And you'd be surprised the amount of systems that I broke, ⁓ because obviously Gotu is a reserved keyword in many computer systems. ⁓ So yeah, I... ⁓

Yeah, apparently that's my biggest legacy at Google is like the amount of systems that I broke is what I'm most famous for, guess. But yeah, I can walk you through.

Warren (01:12)
Is there, yeah,

is there like one particular story that just comes to mind, be like, it was this one time that was the worst.

Sam Goto (01:18)
Yeah,

I mean, there are many over the years because you'd be surprised the amount of systems that have hard coded the fact that go to is a reserved keyword, but perhaps the most memorable one is that ⁓ I broke. So internally, have something at Google internally. We have something like a URL shortener system called GoToLinks. And so the way that they work as you would normally think is that

They have a go-to slash and then you can pick whatever string you want and I can point to any URL and ⁓ I broke them for about four hours at Google and the way that it happened is that ⁓ it was fairly early in my career. was maybe ⁓ five or six years in. I was on the Gmail team. This director comes along and says like, ⁓ hey, ⁓ you know, every engineer gets a new desktop machine. You know, just here's a spreadsheet. Pick your machine name.

And then, and if you don't pick any, I'll just use your username. And so, I saw, I saw like, sure, happy to get a new machine. And then I just get lazy. It's like just using my username. My original one was brazil.corp.google.com. And then my, then my second one was goto.corp.google.com. And so like new machines arrive, everybody's excited about them. I was like, ah, this like a new corp machine that's wonderful. The moment I plugged my machine into the network with the ethernet cable in,

the DNS stuff starts kicking in, registered my machine as goto.corp.google.com, and then all of a sudden, all of the goto links start coming into my machine as opposed to the goto service. so ⁓ for, it was actually pretty fast that ⁓ people realized what the problem was, but it took a long time for the DNS cache to expire. And so like it was ⁓ for a good morning of the company, the company was much smaller, maybe five or six thousand each.

people at the time, but it was enough that he created a big commercial company. All the Goat links were coming to my machine for a good, good morning or so. for a good amount of time, I kept the company unproductive.

Warren (03:31)
That's like one of those secret pieces of knowledge from Google. I feel like that all the user identifiers are actually email addresses, right? So getting the email address in there had a real impact on the URL shortener.

Sam Goto (03:46)
Yeah, for sure. Yeah, I'm GoTo. And then so many things rely on the username, right? And so the other story that I tell people is that at Google, it's a monorepo. And so everybody submits code to the same repository. And there's a special package called experimental packages that is slash experimental slash username. And then I broke that too because mine was obviously experimental slash GoTo.

⁓ which broke because as soon as you put that into a Java file, it goes into the package name. It's experimental.go2.package name, and it also doesn't compile because it's a reserved Java keyword. And so that also broke. ⁓ So yeah, you'd be surprised the amount of systems that people assume that the username is a, it's a reserve, it's not a reserve keyword.

Warren (04:35)
It seems like you've been destined to be some sort of software engineer breaking system since you started out. Did you always know that you would go into software engineering and potentially end up at Google for 17 plus years?

Sam Goto (04:48)
⁓ I mean, it's hard to say. I have to say that when I was in eighth grade, I fell in love with computers. ⁓ I guess in sixth grade, was already, in eighth grade was when I got a Visual Basic book. And I remember that because it was the first time that I read a book faster than my brother. My brother was always the kind of like the well-put and smart one. It was more the funny ⁓ one, ⁓ troublemaker some would say, but it was in eighth grade.

that I remember getting my hands on ⁓ a Visual Basic book and just falling in love with computing. So yeah, I would say that since eighth grade is when I feel like I knew that I, not that I knew, but it hasn't, my curiosity hasn't stopped since sixth grade, since eighth grade, if anything, just grew over time.

Warren (05:38)
How did you end up on the Chrome team working in probably one of the most cutting edge technologies out there today when it comes to containerization and security, something that everyone's using? You mentioned that you were on the Gmail team before. I can't imagine before getting into Google, you're like, you know what? I want to work on browsers. That's going to be my thing.

Sam Goto (05:59)
yeah.

Well, I guess, yeah, mean, a long way. And man, I will just show how old I'm feeling now. But ⁓ yeah, from eighth grade, I think, ⁓ I ran into ⁓ HTML, JavaScript, CSS. I remember just feeling like ⁓ this permissionless environment. remember feeling like as a high schooler, feel like I can't believe that I'm able to do this without asking for anyone's permission. I was thinking like a civil engineer.

require centuries to have a bridge approved, or my parents were doctors. There's just no way they would ever operate on anyone without, and I remember this kid, a 17-year-old, just writing code on the web and just feeling like, man, it feels so wonderful to be able to do stuff without having, ⁓ just not requiring a fancy, ⁓ a lot of economic bootstrap. ⁓ There's a... ⁓

⁓ cinematographer in Brazil that says like an idea in your head and a camera in your hands. I forget if it's Brazilian or not, but there's this thinking of like all you need to do some wonderful stuff in film is to have an idea in your head and a camera in your head. And I felt the same way about computers. So I remember building some of my first websites when I was in high school.

⁓ I spent a year in Italy, which really saved me as a student. It really was a life-changing event for me as an exchange student, spent a year in Italy. And then when I came back, ⁓ got into college, and I remember in college feeling like that my dream job was to work at Mozilla. My high school idols were folks like ⁓ Linos and doing the Colonel, and in college it was Mozilla. I've always felt like.

Mozilla was the perfect job. And Google was just starting along. It was like, remember, because I went to college in 2002. And so Google was still like in its infancy, but it was already something that people would talk about. At the time, ARCA.com was one of the largest social networks in Brazil. don't know if you, ARCA was TikTok before TikTok was cool. Or at least the grandfather of TikTok, perhaps, was Facebook and then ARCA before that.

Warren (08:19)
I have to, I sometimes wonder whether or not the audience actually thinks that TikTok is cool. you know, the...

Sam Goto (08:26)
Yes, yes, a little bit bit of a boy, yes.

But yeah, Orchid was comparable to what TikTok is today. It was a social network and it was the largest social network in Brazil. somewhere in the fourth or fifth year of college, I got an internship at Orchid and I was super excited to come to California to help be one of the engineers on the Orchid team.

⁓ Again, I felt like this feeling of like, man, I just can't believe that they let like a 22 year old write code for the millions of users and just push things out to production. And I remember just feeling wonderful about being able to ⁓ have an effect on ArcGut. ⁓ then ⁓ somewhere ⁓ after that, I ⁓ passed the Google interview. And then at Google, I would say it's been 20 years now, so it's a lot of... ⁓

not 20, 2006 was when I was an intern. So technically next year will be 20 years. But I would say that maybe in my career at Google is maybe divided in three big parts. I would say the first part is like the social network part. So I did Orchid, Google Buzz, part of Google Reader, part of Google Docs, Gmail, and then Google+. And at that time, I like to tell people that I was responsible for the least successful version of signing with Google, which I can tell you a little bit about.

Warren (09:50)
I'm with you. Honestly, I think that the cut over from, I think it was Twitter really that started federated login in my book, but it was Google Plus identities after Wave that really made a huge impact of having the idea of federated login providers out

Sam Goto (09:58)
Yeah.

Yeah, yeah, yeah, yeah. Twitter, a lot of this comes from folks like Brad Fitzpatrick and a lot of the folks that came into Google afterwards. ⁓ Orchid had some of these ideas too. There was something called OpenSocial that we tried for a long time. I think it's comparable to what Blue Sky and Macedon are today, but a way to have social networks talk to each other. And even at that early stage, I feel like I was already kind of fascinated by this idea of having things interoperate with one another. I work on Google Reader. ⁓

with ⁓ where Fitzpatrick and ⁓ Brad were doing PubSubHubbub and RSS. And then after that, ⁓ the second third of my career Google was in Google Search. I was like, enough of developing websites. Let me try to crawl websites. And then I spent a good.

four or five years in Google search. ⁓ For the most part, ⁓ also in doing standards in interoperability. So I did schema.org for ⁓ semantic web sprinkles for Google search. Trying to do the Google system before we had LLMs, and it was really hard. I can talk a little bit about that. And I'm so excited about LLMs today. then about eight or nine years ago, I ⁓ came to the Chrome team. ⁓ Because I spent like 10 years of my life

building websites, five, crawling the web. So I figured at some point, I should try to design the web from within it or from the browser. then so nine years when I joined the Chrome team and have been developing a web platform API since. Did I answer your question? It was a big, big, big answer. But yeah, that's how it got into Chrome, at least.

Warren (11:43)
Yeah, no, no, absolutely.

Yeah, no, that's absolutely great. I think it's a really interesting story and something that at least resonates for me and hopefully some of the listeners as well. And I really liked that you brought up the Federation story because I think that's one of the selfish reasons that I wanted to get you on for today's episode ⁓ is because I feel like the Federated Credential Management...

FedCM is such an important innovation in not just the auth space but really browsers and getting the word out there that this is now a technology that not only can be used but companies such as Booking.com and Shopify I think are the two canonical examples that have already created support for this. ⁓ I'm sure you've got like a cornerstone FedCM elevator pitched down so let's hear it.

Sam Goto (12:34)
I don't know if I do, think, and it's funny because I think the way that we talk about it internally is somewhat different than the way that we talk about it externally. ⁓ But I can tell you at least what's in my heart at least, which is, it's just this intuition.

that ⁓ if the browser was more involved with identity, ⁓ if it took identity as a first-class citizen, then it would be able to assist the user in constructive ways. So it's just this intuition that of like, in what ways can the browser help, ⁓ can the browser take identity as a first-class citizen and help the user? so, because if you think it's kind of like, it's a missing layer in browsers, right, in the internet,

that identity is something that is done on top of it as opposed to in it. ⁓ Identity, tell people that, Federation specifically, both SAML and OAuth have been done despite of the browser, not because of the browser. You surprise the amount of workarounds that people have gone through ⁓ because they assume that browser vendors were kind of like this immutable thing. I tell people, I understand where they're coming from. When I'm designing a browser, I don't think of like, ⁓ what if I changed the laws of gravity?

What

if I publish this paper about how quantum physics works or how gravity works or even operating systems, right? You take the operating system for granted. You don't go like, oh, maybe if only Windows worked that way, if only Linux worked that way, right? You operate it with the constraints that you have and the layer that you're in and that's what you have. And for the most part, think that we went so far in a wonderful way without the help of the browser and both SAML and OpenID Connect and OAuth.

We also created really convoluted systems that have ⁓ bad properties that are fundamentally not solvable unless you assume that you can change a layer under it. ⁓ For a good amount of time, I tried to go to the identity ⁓ conferences. IAW nearby happens a lot. I would tell people, hi, I'm a browser engineer. I'm here to help.

I think people assume that browser engineering is done by completely ⁓ unrelated people that have five eyes or three legs. But they're just done by people the same way that other layers are, and they're as accessible as other layers are. And if you only ask people, how far would you be able to take you if you could assume that the browser could change? And I would just keep asking that question. you'd be surprised the amount of people who said, ⁓

If only the browser could change this in that way, then we wouldn't have to have these and this problem in the system. It would make this part here less convoluted. Some of my pet peeves are...

Redirect your eyes is one example. In all the many ways in which we have to hide the response back to the sample response. ⁓ The NASCAR flag also comes up too as like, if only we had ⁓ a neutral party that would be able to help you discover your identity, that might help too. So yeah.

Warren (15:57)
I

actually want to dive into that because I think the idea of what's called the NASCAR problem comes up and I think it's worth spending one second explaining why I'm so personally invested in seeing FedCM come and make its show for the browsers because realistically it was always the case that in order to select a federated identity provider to log in, the application has to support that specific one and

Sam Goto (16:14)
Yep.

Warren (16:25)
with the number of data providers that we have out there or identity providers that are now available in order to give every user their own control over which identity provider they want to actually use, the list on that login page would have to be, the scroll wheel would have to be involved on the mouse in order to select, and then remembering which identity provider you actually picked. And so for me, I think FedSame is all about eliminating the list, letting the user pick who they log in with, and then most importantly, I think remembering.

Sam Goto (16:31)
Yeah.

Yeah, for sure. mean, that's also one of my biggest pet peeves. when I talk to the... I talk a lot with... I try not to run into the same walls that people have already run into. I talk a lot to the original people that designed some of these things. ⁓

Warren (16:56)
what that choice was.

Sam Goto (17:15)
And they are all kind of like very supportive of, they said, a lot of them say, like, we designed OpenID Connect early on so that you could bring your own. It was just really hard to explain to users. Like you said, right, you either have to have an infinite ⁓ select box with infinite scroll, right? But what they actually did was initially you could enter your OpenID provider in a text box, right? Like you entered an email address, right? And then from there it would like bring in the right things, right? And obviously, like that was hard

for users to understand, right? Who on their right mind say, like, this is my open ID provider, you know? And then they announce themselves as that. so, in as much as it was a good intention, the intention of the design, the properties of the system that they wanted was so that you could bring your own as opposed to have this enumeration of, like, ⁓ preconceived, pre-anticipated, ahead-of-time ones. ⁓ But it turns out that it was just really hard to explain to users in comparison to this

it on a signing with Google button or logging with Facebook button, right?

Warren (18:18)
Yeah, for sure. think now you're actually in a better place to sort of describe the benefits because we can see, I think what you're describing realistically there is like Webfinger for Macedon or Matrix ⁓ or AT Proto for that uses, there's pretty much just OAuth 2 under the hood for Blue Sky. As a user, you still have to remember.

Sam Goto (18:30)
Yeah.

Warren (18:39)
what your email address is or your domain every single time you want to log on. And one of my big challenges with even Macedon is that every time I go there, I'm not on my home domain. I'm on some other domain and I have to then type in infosec.exchange every single time I want to actually authenticate. And that step just completely goes away. And I think for me, as you brought this up a lot, is that the browser being a layer that's been neglected in a way and it's become so powerful. And I think...

Sam Goto (18:49)
Yeah.

Warren (19:09)
One of the flavors to this is that we're seeing more and more attacks that rely on compromising the application layer that's running in the browser, like malicious packages that get in, or we talk about cross-site scripting, XSS attacks or injected JavaScript into browser agents. even outside of everything else, it makes a lot of sense to start migrating the responsibility of critical components into a more secure layer that doesn't change. personally as an auth provider, my company,

But really anyone who's offering any sort of service, we see that our customers, if they all need to do the same thing, if every application in the world needs to do the same thing, then there's an opportunity to recapture that duplication that every application has to build in the integration with OpenID or OAuth or AT Proto, et cetera, and move it out to a cornerstone area that it only has to be once. And now only the browsers necessarily have to ⁓ provide that sort of thing.

Sam Goto (20:05)
Yeah, no, I 100 % agree, but it comes at a cost. before I go over the cost, ⁓ so I think ergonomics is a big important factor. Not having so many people rewrite the same software, it's useful. ⁓ But I often tell people that ⁓ it goes in this order. ⁓ Security, privacy, capabilities, performance, ergonomics, ⁓ and there's a fifth.

But there's a priority of things. And when you said about both making it useful for developers, I think useful, making it useful, performing for users in not having to remember things, I think it's useful too. But I think there's many things that can only be made private if it's at that layer. A lot of this came from the perspective of the ⁓ seven laws of identity. There's ⁓ one.

property of a law, is just to fight parties or data minimization for constraint use, which is that there's just that social login today as it's currently done, it reviews more to parties than it necessarily needs to. And so, you know, as you go along the web and you click on signing with Google and you click on logging with Facebook, both Google and Facebook learns more about their, about what you're aware about than they necessarily need to.

And that's partially because of the construction of the protocol that was used without the browser. But if we introduced the browser, one of the premises was, would it be possible to make it so that you could decouple presentation from issuance and in doing so, being able to have ⁓ you go to websites and log into them without phone homing your identity provider. It's a lot less compelling for enterprises and for research and education. But for consumers, we've always felt like, it would be wonderful if you were on the web and that...

And that tracking by identity providers weren't necessary, a necessary ⁓ primitive if you provided a better one. So there are many angles as to why FEDCM in terms of like both ergonomics and NASCAR flag user performance. But I think ⁓ both the security and privacy aspect I think are pretty important too. In performance, I always tell people ⁓ that I think unification across authentication mechanisms is a key one too. And so... ⁓

So like the browser is the only entity that knows about your passwords and your pass keys, right? But Federation has been done on top of the web. so browsers couldn't really unify everything in a single account user between passwords and pass keys in Federation because it never understood what Federation was about because it was always like a user land construct, not a kernel land construct. But if you move them to the kernel,

then you can unify those three things and offer to the user a meaningful connection. So for example, the NASCAR flag isn't just a problem of reconciling kind of like the five, Facebook, login Facebook, you're signing with Google and it's logging with Twitter buttons. It also has to do with the fact that you don't know if you used a username and password or if you used social logging before. I tell people, my concrete use case is that I personally have two accounts on Yelp. I have two accounts on Yelp because Yelp is a product.

that I use like once every five years when I need to fix my house. And I always forget like what did I use the last time that I went to the DELP? And ⁓ in doing so over the amount of years, I end up like having two accounts. One that I use my username and password and the other that I use Facebook login and there's probably a third one that I use signing with Google. But it has to do with that. The NASCAR flag isn't just the social login providers. It also is the inability of Federation to be reconciled with

usernames and passwords.

Warren (23:46)
See, and I think historically that's been a requirement on the individual application to deal with that reconciliation. Like just in our own product, I know one of the things that our users keep coming back and being like, we really like this feature is that users, doesn't matter which mechanism they pick to log in. If the email address is the same, automatically I'll log them in with the previous one. then.

Consumer applications, as you pointed out, this is critical. And for business applications, you should never do this ever, because it's like a security risk to even do this and like trust whether or not the flag that says email is verified is true or not. Like, I can't imagine just a number of vulnerable applications out there that are vulnerable to data exfiltration by users that logged in with their corporate identity provider, then left the company, still was able to access the email, logged in with the email with a password, the email was never verified, and now can get access back to those systems.

Sam Goto (24:14)
Yeah.

yeah.

Yeah.

Warren (24:36)
And I feel like this is just another one of those situations that just completely goes away. I do like that you brought up Paschis, though, because I do want to get to the comparison there. But you told me to ask you, what about the cost?

Sam Goto (24:51)
⁓ the cost. yeah, because a lot, I mean, ⁓ it's the accessibility web manifesto. Have you ran into accessibility web manifesto?

Warren (25:04)
Not me personally, but I have like three or four colleagues that just every single day are talking to me about accessibility and it's just things that are changing.

Sam Goto (25:11)
No, it's not extensibility. Extensibility Web Manifesto, it's a trade-off between low-level APIs and high-level APIs. ⁓ How can I put this in a way? There's so many analogies. mean, to some extent, it has an analogy to Democrats and Republicans. But let's not go there yet. ⁓ But it ⁓ has to do with how much responsibility the operating system pulls for itself. And the more that it does,

Warren (25:14)
Yeah. okay.

Let's not go there.

Sam Goto (25:40)
⁓ the the the the the more how would I put this so ⁓

Warren (25:49)
I like states versus states rights versus federal union, right?

Sam Goto (25:54)
Well, guess, so the intuition is, topologically speaking, there are lot fewer browser engineers than there are website engineers. And so if you count the number of browser engineers, there's maybe like, I ⁓ mean, maybe like a couple thousand in the world. There aren't that many, right? And they are writing C++ and they're busy fighting fires. And so there aren't that many C++ browser engineers. Like if you count Firefox and...

Chrome and Safari and whatnot. If you put all of them together, I was just at a meeting last week in Kobe, and so there were fewer than 2,000 people, which doesn't represent everybody, obviously. But it's in that order of magnitude. Web developers, on the other hand, you have millions of web developers, right? And so in terms of innovation and ideas, there's just a lot more brain power in user land than there is in kernel land. So usually, browser vendors try to

pull as little as they possibly can and enable the ecosystem to do things in user-line as much as they possibly can because it is so much more efficient to do things ⁓ on top of the browser than inside the browser. And so I always tell people that it's useful to have stuff in the browser when they're boring and ⁓ uncontroversial. Kind of like there's an architectural principle for this, like paving the cow paths. So have you read into that story before, the cow paths?

Warren (27:15)
No, I haven't.

Sam Goto (27:17)
okay, well, this is an easy one to explain. I promise that it has to be. But it's the story about an architect that was building ⁓ in a university. He was tasked to ⁓ help students ⁓ walk through the campus, right? And then ⁓ what he proposed was, let's have everything be grass for a couple of years and let's let people walk.

Warren (27:19)
Yeah, go for it.

Sam Goto (27:41)
And then we'll let them walk, and then whatever there are places where there's a brown patch, we'll pave that. As opposed to anticipate what they want to go to and then just have them cut through corners. And so that's what they mean by paving the cow paths, which is just let the cows move. And then they will move. And then once they move, they will have discovered what is the optimal path from point A to B or where they want to go. And they just pave that. And so the same way for brownstone engineering, ⁓ that's the

Paving the cow path is term used for kind of like let web developers figure out how to ⁓ innovate and compete in this beautiful boiling pot of ideas, Where competition and just a massive amount of them. And then whenever things sediment and they settle down and they become boring, bake that into the browser, right? Because once you bake that into the browser, Once you pave something, it just stays there forever.

Right, like when you use pave something, it's just really hard to take out. And so, because it's a lot more durable and solidified, right? But it's also not as flexible, right? People walking by places a lot faster than people like paving things. And so, browser vendors are, the trade off is that, ⁓ yes, it's not always better to have stuff in the browser because once you stick into the browser, it just becomes a lot more ossified. You know, it's harder to change, takes longer to recompile, to redeploy.

and you have to agree with a lot of people. Whereas if you do this on the user land, it's a lot more innovative and it's more exploration. So when things are bubbling and things are exploring a lot, then it's not very useful to big data to the browser. That's a trade off. It's called accessibility web manifesto.

Warren (29:20)
Yeah,

for sure. You have to deal with this principle really of you can't, not that you can't break the clients, the websites, et cetera, but realistically what you're doing, no one will adopt the new thing if they don't have to. And if you do break existing websites, no one will adopt the new browser. So you're sort of a host there. It's interesting you draw that analogy though, because I've always considered engineers to be more like herding cats than cow paths, but.

Maybe that's just my experience.

Sam Goto (29:50)
There's a lot of that too. There's a lot of that too. Yeah. You'd be surprised how much of that there is for sure.

Warren (29:56)
So one of the biggest problems I've seen with browser technology, especially when it comes to optional things and specifically in the security domain is first of all, security doesn't like reduce costs. doesn't like actually, people don't actually care about security in a lot of cases. And I have this feeling that pass keys failed. I'll say WebAuth and Fido too. ⁓ There are a lot of things that it's good for. It's pretty much just an evolution of smart cards though. Second factor, ⁓ attestations and replacing TPMs or

⁓ HSMs that most desktops and laptops just don't have the ability to have a black box private keys. And I think it's not about the technology because it's great. I think just with that, and hopefully everyone knows what I just said there, and if you don't, I probably have like 20 or 30 blog posts about what those things are. I think the biggest challenge realistically is that the buyers are not the users, right? Like the people that have to actually implement that technology are at

companies and I think you're gonna have a similar problem with the application development today with FedCM, whereas you need to convince all four sides of your platform to start picking up this technology, right? You have the end users and you have the browsers, you have auth providers and you have the application or federated identity providers and you have the application level there.

Some people really want this, right? think everyone will jump up and down, especially me saying, FedCM, best thing ever as a user, I want this yesterday, all the browsers support, et cetera. But if you look at the internet ecosystem, there's still something like 50 % of websites on the internet are still being run on WordPress. And I don't know if I trust this number anymore because WordPress is the one pushing it. ⁓ But even if it's remotely correct, I think the biggest challenge there is how do we convince

the application developer teams and really their companies to do this migration, do this change and support this new technology which will really be better for everyone.

Sam Goto (31:58)
man, that's a really tough question. I can't say that I have a perfect answer, but I can tell you that I've spent an absurd and unreasonable amount of time thinking about it and that my strategy is at a minimum deliberate in that, but it's hard to say if it's gonna work or not.

I mean, if I understood you correctly, you're asking, like, how do you bootstrap the ecosystem? know, there's a cold start problem. It's a four-way cold start problem, because you have to convince users, developers, identity providers, and browser vendors that this is a good path to take. And you're right ⁓ that it is a four-way cold start problem. Did I understand your question right? that what you're Yeah, so it's ⁓ a...

Warren (32:37)
Yeah, absolutely.

Sam Goto (32:47)
⁓ How would I put this in a non-conflutated way? Maybe I should just give up and give you the confluent way. ⁓

The ⁓ way that I would explain the strategy so far, which I think is reasonable strategy.

So it's based on the essay by ⁓ one of our internal strategists. left Google recently, a couple of years ago. He called this the ⁓ self-sustaining flame. Have you heard that term before, self-sustaining flame?

Warren (33:29)
⁓ not outside of the Kabbalah.

Sam Goto (33:32)
So self-sustaining flame is a, I would say it's a ecosystem strategy, ⁓ which ⁓ is in opposition to ⁓ what Alex Komorowski called the flamethrower. So I'll tell you, like, since I've been about 20 years at Google, I've seen a lot of ecosystem place, but the more traditional one is what one would call the flamethrower. The flamethrower, which some would argue that Pesky takes some of this approach, but...

not to... ⁓ So the flamethrower analogy is the typical ecosystem play that you... It was in opposition to this ecosystem play, but the typical ecosystem play was that we would come up with something and then we would go at Google I.O. and then we would just throw a flamethrower at something and say like, use this, right? And like that happened for things like Dart and...

know, Wave, and I forget exactly all the many other products, but like all the other, was, that is one ecosystem strategy, is to come up with something and then just throw a flamethrower, using the loudest flamethrower that you can possibly have, and Google IOU is probably one of the largest that Google has, and other one of those. So this product manager came up with an alternative ecosystem play, which he called the ⁓ self-sustaining flame. And the self-sustaining flame,

was a much more, it had to do with feedback loops. And it find a way to have the feedback loop feedback in a constructive way. So set up a feedback loop. And so his premise was instead of throwing a flamethrower, because a flamethrower goes very fast and it burns the thing, but then it kind of goes down afterwards. Instead of that, do this instead. Find a minimal viable audience for something that you need. And then from that, start, ⁓

building an ecosystem in such a way that the more entities you start engaging with, start providing value, the bigger this becomes and the more it will pull other people into. He called this the gravity well, which is if this was ⁓ a solar system, the more planets come, the more it pulls, the more ⁓ shapes the fabric of space and the more it pulls other people into that space. And you do that incrementally as opposed to as a flamethrower.

And so many of these things I think will give you a couple concrete examples is I love, I don't know if you heard about QUIC, but QUIC is my favorite internet protocol, ⁓ TCP IP over UDP, and that was only possible to be done ⁓ because ⁓ Google kind of owned both Chrome and YouTube, and they were able to design something that was good within that small, minimal, viable audience. But as soon as you do that,

You know, other people like at Akamai say like, wait a second. No, I could take benefit of this too, cause you know, yeah, this sounds a bit faster to CPAP for sure, right? And then other brands are saying like, yeah, why would my users be slower on my browser? Am I all take quick too, right? And then it kind of create this feedback looping, which quick just turned into like this wonderful, beautiful thing. It's my favorite project for what it's worth. wish I had done quick, but unfortunately I don't have a time machine. But Fetsyam, it operates in a similar way.

which is, like I said, was the tech lead for signing with Google like 15 years ago. And so I figured, you know, what would happen if I was able to have been the tech lead for signing with Google 15 years ago and kind of like know a lot of the people and also be able to change the client, you know, what would happen, you know, if I could do both, right? And it just happens. again, a lot of this is not new ideas. lot, I credit a lot of the ideas for FetchCM actually they derive from Mozilla personas.

from whom I took a massive amount of inspiration and talked to a bunch before starting FETCM. But it was this idea of if you were able to change the client and the server, would you be able to create a gravity well? And so for the most part, we did Chrome and signing with Google in a way such that we asked ourselves, let's do this such that it creates a gravity well, but let's make it so that any browser could take advantage of this too, and any identity provider could take advantage of this too.

And so having that first connection with Signing Google and Chrome, always obviously doing in the open, meaning that a lot of this was developed in the open, right? But it was important for us to find a minimal viable audience. And because Signing Google is a massively successful consumer product, and it has massive penetration across many websites, we were also really smart about

And this is, I think, I can say it is my credit, which is we figured out a way to redeploy signing with Google without asking for the relying parties to change, largely through JavaScript SDKs. And more recently now we're doing HTTP headers, but the trick that we played is that a lot of...

The way that sign-in Google is deployed across these many websites is that they embed a JavaScript SDK that the website embeds in pools, in the user pools dynamically, right? And so we said, well, what if we have the JavaScript SDK call FETCM as opposed to do a top level redirect so that they could call FETCM into this as opposed to do, and would that work, right? And so it spend like a year and a half testing technical feasibility. At some point, we convinced ourselves we think we can deploy this across every website in the world.

that uses the JavaScript SDK that Signing Google does without just changing the browser, just changing the identity provider. And so today, if you fast forward from that initial intuition to today, 3 % of the, we migrated most of the Signing Google traffic to FedCM, and about 3 % of the websites on the web uses calls into FedCM, just because we managed to deploy that over JavaScript SDKs. And so that created a gravity well that I won't say that it,

We should take for granted it will actually work, but it created a gravity well in which ⁓ the vast majority of the web uses FedCM in terms of websites that you go to. There isn't any that you can go to that wouldn't have an integration apart from banks and healthcare providers. But from a consumer perspective, there isn't anywhere on the web that you can go with Chrome that ⁓ you wouldn't be able to take advantage of FedCM because both Chrome and the IDP and ⁓ the JavaScript is to get changed.

And that created the, and that we hope, right, that that created the beginnings of a self-sustaining flame. Because right after that happened, a couple years ago, Shopify came along and said, wait a second, we have, can redeploy RPS and IDPs the same way. We're gonna, what if we did that for all, merchants, right? And so Shopify came along and then in a similar, but different, they don't use JavaScript SDK the same way, but in a similar way, they were able to deploy FETCM across

all of their merchants, and there are hundreds of thousands of merchants that Shopify supports, And then PayPal came along, then email providers are coming along in terms of email providers, and then Firefox is coming along. Firefox has always been very supportive of FETCM, although they're massively understaffed. And every time that it goes through around that basic gravity wall, it pulls more and more.

And then Safari has always been also supportive, but also kind of like a little bit more cautious about like how you relate to other stuff. ⁓ But we never got anyone from Safari saying like, ⁓ this is like directionally incorrect. ⁓ so, I mean, it's yet to be seen if it's gonna work, but it is a very deliberate strategy called self-sustaining flame, which is one in which you try to find a minimal valuable audience to kick off the ecosystem and then pull more and more and have...

and have each entity that joins the ecosystem provide value to the ecosystem itself, and then in the hopes that at some point it will have gained enough momentum that ⁓ any other entity could just pull and it wouldn't destroy the gravity well.

Warren (41:46)
Makes makes a lot of sense. So just to clarify here the since the integration in Chrome and you know, it's to be Firefox or is supporting fedcm applications that Support login with Google are actually already using fedcm to authenticate and letting the use login Does that mean that without any changes on the application side? users that bring their own identity provider or you know other identity providers that are Supporting fedcm can already be used to log into those same websites

Sam Goto (42:16)
Well, there's a limit to how much backwards and compatible things you can do. And it is the case that we have been able to deploy signing with Google, for the most part, in a backwards compatible way from the client side perspective. The application server, though, does expect that it's harder to redeploy at scale. Every application has to be deployed individually for it to enable things that go beyond a signing with Google integration or a signing with Shopify integration, right?

⁓ except that Shopify controls both the RP, the application, and the identity provider, so they're able to ⁓ augment it with things like you suggested, like being able to bring your own, right? There are other parts of the ecosystems like ⁓ Axle Springer and the NetID folks, they also have more control over the line party and the identity provider, so they can augment with more of those things, like the bring your own IDP ⁓ premise, but for the...

But it's not true that you can like out of a sudden just redeploy all the applications and provide all the features that you want to provide them. There's a limit to that.

Warren (43:21)
I think I want to reiterate the relying party is just the application running in the browser. So the problem I think realistically is here is it's not replacing the mechanism by which ⁓ you're consuming the JWTs, the JOTs that are coming from the identity providers. Those are still exactly the same. The only difference is the user experience that causes those tokens to get generated, which means that realistically as a application maintainer or developer, you are now going

The thing to do is not change any of your technology, but change your assumptions on where those tokens can be generated from. And it's still a real problem that you'll need to figure out, okay, if the token came from Google, how to verify ⁓ tokens from accounts, google.com slash OAuth, or if the tokens came from somewhere else. So likely you still need ⁓ some attention there. However, I will say that if you're using ⁓ some sort of identity aggregator, so ⁓ either

not to say that my product's the best in the world, but if you're using Authress that solves it for you. you're Fusion Auth or Auth0, potentially they have solutions as well that automatically do this aggregation for FedCM-based providers, which means that if you are using an identity aggregator and you didn't just roll, log in with Google yourself or log in with Shopify, you already have this capability of providing this functionality to your users in a way that's completely transparent to your applications as well.

Sam Goto (44:39)
Yeah.

Yeah, for sure. And I think that's the next trick to play. Like we played a trick with JavaScript best decades, and I think it was pretty cute. But I think the next trick to play, I call these frameworks. I don't know if that's the right term, but it's, but yeah, for sure. Like, ⁓

off zero, Okta, Fusion off, your company, right? All these companies that provide off services for other companies, right? Have the ability to change so many applications just by changing that one entry point, right? It all has to do with leverage, right? What is the leverage point that we can insert the thing so that we can move a mountain, right? And I think that frameworks, that's why I said, like we said, WordPress accounts for 50 % of the web. That to me is actually good news because

that means that we can just go to WordPress and say like, hey, do you mind supporting FedCM up from the get-go, And then we just enable 50 % of the web, right?

Warren (45:35)
Good luck with that. ⁓

I mean, I always say that because like they don't even have their own like sign in widget for a federated identity providers. You need to first install like a third party plugin to make that happen. But I'm sure if you search for the WordPress plugin store right now, there's already a FedCM, you know, identity provider plugin. I know, you know, we have one and all zeros got one and et cetera. So that's just one way to make the WordPress stuff just work out of the box.

Sam Goto (45:46)
have a plug in. ⁓

Yes.

Yeah.

Yeah.

economically, the way that I see it, at least, that economically, it's just one website competing with one another. So the one that has the least, the higher conversion roles in acquisition funnels just have the feedback loop. Off Zero just have the desire for competitive advantage to perform higher conversion rates in acquisition funnels than Fusion Off and other companies. Right? And so they would just...

Not using FETCM would just be a competitive disadvantage to the other one. But I always tell people, go to the second one, not the first one. It's always easier to have the second place ⁓ jump the incumbent, then have the incumbent adopt something.

Warren (46:33)
Yeah.

Well, I love this, so it's coming for us and our users specifically. I still think the selling point actually is out of the application developer hands. It's in the business organizations that are deciding where to put their development resources. So the question at the end of the day becomes, if you're using one of these open source frameworks or using a SaaS provider, what is the complexity for validation, for testing? What is the configuration required?

I know for open source stuff, it's a little bit of a challenge. You have to probably upgrade five semantic versions and deal with breaking backwards compatible changes. But for SaaS providers, you click a checkbox, and you're ready to go out of the box there.

I think that we didn't really touch on it, but it's worth reiterating. One of the things that really comes down here, I feel like, the user experience. If we're improving anything here, it's the UX over ⁓ security or ease of development or anything like that.

Sam Goto (47:51)
Yeah, I agree that we have a design principle at the tech called the priority of constituents, which is user first, developer second, browser engine third, and technical purity fourth. And you'll be surprised how often that is to be said, because you'll be surprised how much technical purity comes first. But users first is for sure like ⁓ is what I think

myself included, is most obsessed about in FedCM's design, which is ⁓ how do you provide a really good compelling user experience? ⁓ it's something that think, it's something that, it's the role of the browser is to.

is to make it so that it serves the user for the most part. There are a few things that think we, that we think that occurred to us that we felt like, okay, we're gonna be, you know, like, let's not win by playing the same game, but by just inventing a new one, was access to...

user access to real estate that developers don't have access to. So for the most part, a website or identity provided only has like a rectangular box that it can work with. It's a pretty big one, right? But it's a rectangular box that you can put your HTML, CSS, JavaScript. Everything outside of that has never been accessible by websites, right? You can't change the back button or the reload button. And the part that I like most about the UI is the URL bar. I don't know if you've seen some of the UX explorations for it, Sam, but a lot of them have to do with like access

browsing ⁓ browser UI, parts of the UI that just are inaccessible for websites. And so the URL bar, that's what I mean by like, what would happen if you pull identity into the browser as opposed to over the browser, right? Because on top of the browser, you only have this rectangular page here. But if you bake it into the browser, then you have access to like places that you wouldn't normally have access to. Like I like the URL bar because I think my hope is that it could represent ⁓ logging state on the web.

that when you get logged into the website, you at some point, like the URL bar lights up and says, you're logged into the website, right? So then we can do log out too, right? As opposed to clearing cookies, right? But then when you're logging into the website, you're able to offer a set of options. You can log into the website with your passkey, your password, your federated assertion, or whatever would come up in the future. But it's the ability to go to a... ⁓

anticipated, a predictive place, right, that you go to and think, oh, this is where you click to log in to the website, right? Or this is where you click to, like, reload the website. This is where you click to go back or forward on a page. But this is where you go to log in. And for the most part, like I said about CalPath, right, most websites, like, there's a user behavioral...

thing that we form, right? Which is most people when they see like when I'm logging this website, they look at the top right corner, right? There's a login or sign up link that you click and stuff happens. What if we pull that out of the corner of the page into the corner of the browser? Would that create the right dynamics? So yeah, so the UX, I think, has always been important for us to not compete in UX that you'll be able to compete in user land.

Warren (50:55)
Yeah, I think.

Sam Goto (51:06)
You know, like, let's, let's, because we will never write more CSS and JavaScript and CSS than two million developers. know, C++ Turbo is the worst, it's like the least ergonomical language that one can choose to write. And there's just so few of us, right? It's so, like, let's not compete there. Let's compete in a place that just wasn't accessible. What is the thing that would be just different from everywhere else? And I think that both in terms of UX construction, but also in terms of the ability to unify across websites, right? As you're going across websites,

is also something that a website can't jump across websites. So if you use your site in Google account here, maybe you also want to use it there. If you use your enterprise account here, maybe you also want to use it there. And maybe the choice that you make across passwords are consistent as you go across websites, and we can reuse that too. And so those are the UX advantages, I think, that the browser has that we're trying to take advantage of.

Warren (51:59)
I think it's a long time coming, honestly, because the more control, with authentication, that moves out of the application land into browser really prevents vulnerabilities in the number one attack vector of all time, which is social engineering through phishing attacks. And by moving that out, you pretty much are, I mean, it's not a direct elimination because, I mean, of course people can still fake what is being shown there and displayed, but eventually there's no way that...

browsers will allow applications to make real changes to the outside that window as you mentioned. Because historically it was the case a long time ago, right? Browsers allowed websites to make change to the URL bar, to the back button, right? Like even that's gone out the window, you can't really stop back pushing or ⁓ blocking navigation. There used to be a thing about pop-ups. Safari does this really annoying thing where if you wait too long before...

Sam Goto (52:47)
yeah.

Warren (52:51)
making a page switch or URL change, it blocks the action, saying that the user didn't cause it to try to prevent, you know, pop-up explosion. So, I really do hope that there's more configuration to come with the configure, like interactions with the browser from the application land. The number one thing that's always on my mind is, can we get access to the TPM?

Sam Goto (52:58)
Mm-hmm.

for sure, have you run into DBSC?

Warren (53:14)
So I tried engaging with DBSC. So DBSC is the device-bound session credentials. And I think the idea is pretty fantastic, that it locks away token ⁓ session continuation into the browser. My problem with it is that it doesn't solve any attack vector that I care about. Well, yeah, but only during ⁓

Sam Goto (53:38)
address is cookie-teft, right?

Warren (53:43)
after the session's been started. the real problem is that you can force cookie regeneration, a new login, as a malicious attacker, anytime you want, and then control that session instead. And realistically, I want a way for the whole OAuth 2, or iOpenID, or SAML process to happen without the application being able to do anything about it, or access to the TPM in a way that can secure the credentials. And DBSC doesn't solve that for me.

So I love FedCM. really hope that there's a strategy. Access to the TPM will get it for me because that will allow us to verify, like basically fingerprint the devices and ensure that they're secure and that the credentials are never taken away. And it allows us to do really interesting things where we can bind the JWTs that are generated to the actual device. Whereas what's happening right now is with DBSC, the JWTs aren't being bound to the device.

they're being bound to an area of the browser which is not accessible by the application. And while it's nice, it would be really nice to have something like a delegated proof of possession, and I'm going to use some complicated OAuth 2 stuff here, so anyone who's not following, don't worry about it. That's just me from the OAuth 2 working group that is paying attention. That allows you to restrict who can actually use those JWTs, and allowing you to restrict them to the specific device is really critical, and I would really like to see someday

like the spiritual successor to DBSC where the browser is starting the off-flow, it's ensuring device credentials, it's signing tokens with the TPM, the onboard black box private key to ensure that the communication is actually tamper-proof.

Sam Goto (55:26)
Interesting. don't know. mean, the other thing that I can, at least I can give you sense of something that we're working on is called delegated FAT-CM, heavy-run delegation-oriented FAT-CM. We're probably using delegation-oriented in a different way, but it's kind of like a three-party model, like an issuer-holder-verifier model. ⁓ Have you run into that, the SDJOTs?

Warren (55:33)
Okay.

Please.

Mm-hmm.

I've seen SD Jots ⁓ mostly for, I think the canonical use case, especially in Europe is like, you want to get into, mean, obviously, no one cards you at a bar here, but in the United States, you know, just as an example, you want to get into a bar and there's an age limit, you know, you to be 21 or older, you shouldn't have to tell everyone who you are in order to verify that you have, you're holding a credential that verifies your age. And so basically the issuer is the government institution, the verifier is of course the device that the bar is holding.

Sam Goto (56:03)
Yeah.

Warren (56:17)
you as the user contain that credential and you can just pass the necessary part over. So, go ahead.

Sam Goto (56:22)
Yeah,

that's roughly it, but for social login, I think. In the sense that, for account login, in that, I mean, the feature, like I said, it would be wonderful if we could make it so that you could log into websites without phone homing your identity provider. And so that's one of the ways, and the reason I bring it up is because we are, the browser is, for the first part time, like actually signing something.

Warren (56:47)
Yeah.

Sam Goto (56:47)
You know, it's

taking something that gets issued by an identity provider and then gets presented by the browser. And so in doing so, we are going to be signing things. so having it be like bound to a TPM, for example, could be an incremental step for us.

Warren (57:02)
Yeah, I think it's the other direction. I don't particularly care if the... You mentioned Google, etc. So one of the biggest concerns with logging in with Google everywhere that people have often is exposing to Google that they've logged in. Now, I don't believe Google does anything useful with this information whatsoever. But if you're logging in with Facebook, they are for sure using that data for malicious practices. And maybe I shouldn't say that. I believe they're using it for malicious practices. ⁓

It's my opinion, I have no evidence, let me get that on record right there and so no one will challenge me specifically. ⁓ But I think that's really the problem and I actually am more concerned about providing my email address to the individual applications because they're going to take it and turn around and sell it or they're just going to have a data leak where someone gets it anyway and now I get spam in German all the time because I live in Switzerland so why not.

And I know someone sold my data, sold my email address, and I would really love to just be able to have infinite aliases for email addresses. And FedCM solves this for me because I can spin on my own identity provider or using our product and create dynamic aliases which are provided to the individual application. So I don't need ⁓ an extra level here for delegation, et cetera, passing it along, I think, with FedCM. You've solved my biggest concern with...

Sam Goto (58:12)
Yeah.

Warren (58:23)
browser authentication, user identity management for applications, and honestly, the last 20 years.

Sam Goto (58:30)
Well, that's an over. I would love if that was true. It wouldn't be for the lack of trying. I'm glad that you're finding it to be of your service. And yeah, I'm super excited to see. It's hard to say. I mean, we have tried this. There's like 100,000 dead bodies before me. But I just know that it probably went farther than most people have in that specific mission. ⁓ But it's still a bit too soon to know if we're not going to run into another wall. But it won't leave you for the lack of trying.

Warren (58:59)
Yeah, and I think it will live ⁓ and it won't just perish. So it will be there in the browsers and as long as it actually gets out in Firefox, ⁓ then I think we can be sure that it's gonna have a long lived history there, especially now that there's no Internet Explorer and Edge or Quantum or whatever they're calling it is built on top of Chromium as well. We're gonna, we have PEDCM on the Microsoft side as well.

Sam Goto (59:22)
Firefox has always been very supportive. I mean, because so much of it is inspired by personas. They were ahead of their time, I think, in many ways, or perhaps doing it the wrong company, perhaps. They didn't have a big identity provider at the time, close by that they could work with. So Firefox has always been very supportive. But they are also massively unresourced. They have a lot of resourcing constraints.

Warren (59:28)
Yeah.

Sam Goto (59:52)
I don't blame them for pausing the development, the implementation of HCM. It's something that if I were on their shoes, I would probably make the same call. But it's good to see that they are just like a heaven.

Warren (59:59)
You're-

Sam Goto (1:00:04)
having philosophical alignment is already like 80 % of the way, you know? Like I think things just converge, like if it's just execution, they would at some point converge. And I think to a large extent, I also feel that way with the Safari engineers. know, like almost everybody that I talk to, they're like, yeah, you know, this seems directionally correct. And like, we just don't know. We were just partially waiting for you to like...

A lot of people are skeptical if we can pull this off in terms of, like I said to you, the bootstrap, the cold start problem. A lot of people are ⁓ skeptical that we can pull this off. And to some extent, I'm still also am not confident about it. So I do feel that it at some point converges, but it won't come for free. It would just be hard work that we'll do one step at a time and at some point we'll get there.

Warren (1:00:49)
If anyone who works at Safari or Firefox, you know, wants to come on the podcast and, you know, share the whole story and architecture and complexity there, I'm, I'm, I'm all for it. Definitely. think, as you said, because it's a four-sided platform, you do need each side to sort of sign up for it. But the fact that basically applications and identity providers and users have all gone full in with this. It's just a matter of having all the browsers there and Chrome, Chromium driving Chrome and an edge there. It really is just Firefox, which.

is going to, I think is going to convert. And then we have this technology and you know, this, like I said, I think it's a huge success. One thing I do want to make sure that I get out of you though, as you said, you were at the, I think it's the largest browser conference in the world this year, right? ⁓

Sam Goto (1:01:34)
It's called feedback.

It's very technical. It's for browser engineers or browser vendors. it's very technical that way. Yeah.

Warren (1:01:40)
What's

coming down the pipeline there?

Sam Goto (1:01:44)
So TPAC stands for technical plenary something, but it's like an annual conference where it's the biggest one from the WGC where all the browser people go, not just browser engineers, but just across product management, UX design, UXR, and engineering. But it's very technical in many ways. And it ⁓ usually has, for the most part, representation of browser vendors, but also developers. And so you have Safari, ⁓ Edge, Mozilla, Chrome, Opera, Vivaldi, all the browser vendors there, Brave,

of like trying to find, tell people, I tell my family at least, the way they describe it then, and it sounds like the UN convention, the United Nations convention, where each country sends their diplomat there to try to find, because it's like everybody there cares about the web.

So it's like the web against the world in that way. they obviously have their own companies and each browser event has their own angles, right? In terms of, they don't always agree on things in terms of privacy, where to draw the line of security, inconvenience, so on. But they're all like passionate about the web. They all want to defend the web. So that we have in common. And it's a whole week. It was in Kobe, Japan this year. It fluctuates between North America and no North America and...

And then what you said you asked what what is it like so like every year I think ⁓ like people go there you have some of the persistent working groups like the same way you have ITF you have the all-off working group and the DNS people the SMTP and pop people and ⁓ in the WTC you have like the payments group the Web of End group you have the you have a massive amount of like HTML rendering people, know CSS rendering people and You have networking and so on. ⁓ So you have these

that people actually need to get work done. But the best part of TPAC, as most people would say, is what we call the hallway track, which is not what happens on the sessions themselves, but what happens on the hallway. Because it's like, I told my son, he asked me, what was it like? And I told him, it's a lot like a science camp that you go to, that you sleep together with. We're all in the same hotel, so just think like 300, 400, like.

People like they're passionate about the web they leave and breathe the web they want to help the web and they all go to the same hotel where they sleep in the fourth floor and then they work on the the on the on the on the in the rooms and It's like a science camp in that way And so the hallway and the dinners and the breakfast is where I would say most of the work gets done and I have to say that

Like the discussions, they fluctuate as the year goes by. If you think about like maybe five or six years ago, blockchain was probably dominating a bunch of stuff, you know? But if you go all the way back to like 2008, 2009, was a lot, the rise of...

native apps like iOS and Apple and Android Play Store and how does the web compete with those walled gardens? A few years ago it was the social web, it was the rise of Facebook and how do we make it so that Facebook doesn't entirely make the web walled garden? So, kind like the...

The concerns and the discussions, they fluctuate over the benefit of having been at Google for 20 years. I've seen a lot of these things come and go. But I ⁓ would say with confidence that this year it was a lot about AI. Just a lot of people were just, I think it's like one of the...

most insane things that we've done in the world as humankind and most people was like, yeah, there was a spectrum of like, man, we're gonna die to like, man, this is beautiful. And so AI was very polarizing as most good things are or most bad things are and I think AI was probably the hot topic and ⁓ I just think it's, I felt at least that it was beautiful because

Like, if you go back to 2008, the period between 2008 and 2016 was the rise of native apps, Android and iOS apps. It's like all the VC funding was going there. And I remember a time where people were like, is the web going to survive? Because when WhatsApp came along or Snapchat came along, they were like, I'm not going to build a website. And they still don't, I think. TikTok doesn't have a website that you can go to. And so Uber, TikTok, and Snapchat, and WeChat, none of those things have websites.

was a really dark period that a lot of people said, maybe the web's gonna die, you know? Maybe we don't, that was a good ride, but we're gonna need it anymore. But so, it was wonderful that we, that the time that we're in right now is like this AI thing where everybody's asking, you know, no, no, my AI browser is better than your AI browser. like, my AI protocol is better than your, MCP is better than A2A and whatnot, More so than like, you know,

Does the web even have a role here? So it was a different vibe, but I think in many ways more optimistic than a few years ago.

Warren (1:06:39)
Has the building of walled gardens, I think a lot of the data is being sequestered behind these. Like we can see that the reddits of the world, even Google search is limited in what it has access to and that the data has almost priceless. Like these companies don't even want to sell what they have, instead use it to train up LLMs, et cetera. Has that had a big impact on say the direction that you're?

you may have or your thoughts on where a browser such as Chromium would go in the future.

Sam Goto (1:07:10)
I mean, some of the discussion, a lot of people are kind of like, they're trying to think in terms of ⁓ the web, like how do we monetize the web going forward? know, like...

Warren (1:07:22)
Unfortunately.

Sam Goto (1:07:23)
Yeah, and by that I mean like people producing content, like for example yourself pushing a podcast out, right? You have to pay rent. If you live in Zurich, your rent is probably really high. And so the content creators, they create content. I mean, ⁓ someone brought that up.

that a lot people create content not for the sake of paying the bills, but because they actually want the content to be out, which is perfectly fair. But it is true that ⁓ things need to be economically viable for them to be economically viable at all. And so for the most part, ⁓ for better or for worse, ads has really helped ⁓ make a massive amount of content on the web ⁓ accessible, but just by having a few people

pay it, you know, like, because a lot of people, I'm not an ads person, so I can't really say this, but ads has, like, for the most part, like, funded a lot of the content creation on the web, right, with subscriptions being, the opposite ⁓ monetization strategy. And subscription, think, ⁓ have completely different problems in terms of, who has access to those things, and it tends to, like, have, like, content be produced for ⁓ the rich, but the...

that doesn't propagate back to the less financially ⁓ able. And ⁓ and ads has all these different set of problems of like click bait and all the, yeah, ads isn't perfect either, But the challenge is that for the last few years with search engines, a lot of the content production on web has already been hard to monetize.

there's a sentiment that it will get harder as we get into LLMs and things that traffic doesn't go as back as it was for search engines. so ⁓ there's some questions about like, are asking, I think everybody is hoping that we'll find a way in which the web will remain healthy and prosperous while we go through this change.

Warren (1:09:42)
I like the sentiment, both optimistic and realistic at the same time. ⁓ I think that may be a good moment before we get too much into the philosophy of that to switch over to picks for the episode. So Sam, what did you bring for us today?

Sam Goto (1:09:56)
Sorry to say that again.

Warren (1:09:57)
Well, let's switch over to pics for the episode. So what pic did you bring for us, for our audience today? Yeah.

Sam Goto (1:10:04)
⁓ as a recommendation for reading?

okay. ⁓ okay. Let me see.

Warren (1:10:12)
Well, you said before that you thought you had figured it out and now we've had a long conversation and you're second guessing whether or not you want to go with what.

Sam Goto (1:10:18)
Well,

I'm trying to find something that might be more related to what we talked about.

Warren (1:10:24)
don't

you don't have to worry about that you know i just picked the thing that you know at the most flavor that we were as a person more so that you know something that has to be relevant

Sam Goto (1:10:34)
well, okay, just so that, just so that people have a... ⁓

something to anchor on something concrete. ⁓ I subscribe a lot to the Seven Laws of Identity that King Cameron published, along with many other people. ⁓ So I would refer to, in the identity of space, Seven Laws of Identity, ⁓ I abide to lot of those principles. And that has guided a lot of my work. If you haven't run into personas, Mozilla personas, I would encourage you to take a look at that too. ⁓ It should give you a sense of at least what my head is at in terms of inspiration. ⁓

like my Beatles, know, if Taylor Swift, it's my Beatles. it's, a lot of personas, if you read personas, think you will say, ⁓ I know where Sam is going to, or like, I understand why he took these steps and I know where he's going to. And... ⁓

Yeah, so work-wise, think, sorry, not work-wise, but that I think is what I would ⁓ encourage you to read. ⁓ Just also work-wise perhaps, but a little bit more ⁓ career guidance-wise. ⁓ I ran into a massive amount of good stuff at Google. ⁓ Yeah, like I said, ecosystem building, I would encourage you to read Komorowski. He was a, he published a bunch. The Self-Sustaining Flame is a good essay. ⁓

⁓ But just more ⁓ career-wise perhaps, ⁓ I ran into The Egg by Andy Weier, which I thought was pretty cool and I think that helped me a bunch. ⁓ The selfie gene is probably a lot on top of mind for me too.

Warren (1:12:11)
Maybe let's

jump into the egg. I find this really interesting because I also like the egg. I had read this probably at the dawn of the internet, because it's quite old at this point. I never realized that much later I then read The Martian and Hail Mary and whatever the one is that's on the moon. I didn't realize it was the same author.

Sam Goto (1:12:29)
Yeah.

Yeah, that caught me by surprise too.

Warren (1:12:38)
Yeah, it's just such great and the egg is like pretty short. It's a short story, right?

Sam Goto (1:12:42)
Very short, so yeah, so it's for one, it's easy to read, like it will take you less than two minutes. Two is very entertaining. And three, I think it can really open your mind. If you don't mind me making concrete, I can tell you how it helped me, specifically when it comes to ecosystem building and so on.

So I guess, just in short, the egg is a story about a person that dies. It's a story, like maybe a couple of minutes. But the person that dies, they meet their creator, and then they're talking to their creator, like, oh, I'm dead. the creator is like, welcome to this, and you're dead, and so on. And then as they realize what they're going through, the creator said, oh, get ready, because you're going to reincarnate. And then this person goes like, oh, interesting. So the Hindus were right, and so on. It was like, well, every religion is right in one way or another. And then they say like, oh, wonderful.

Oh, you're going to come back and, you know, you're reincarnate about 200 AC in a Chinese village. And then the person was like, oh, wait, I can go back in time? I didn't know that. And then the person said, the creator says, yeah, yeah, you can go back in time. And then, and then so on. It was like, oh, well, if I go back in time, does that mean that I have running to myself? And he said, yeah, yeah, you probably run into yourself a lot and so on. I'm like, that's interesting. And then I was like, well.

how does that even work? If I can go back in time and can run into myself, what happens if I interact with one another? And then the creator goes like, well, you were.

you were all the people, you're like everybody that lives in the world is you and you are everyone. And the person was like, was I Jesus Christ? And then the creator was like, yeah, you were Jesus Christ as well as their disciples. And I was like, what was I, Hitler? And I was like, oh yeah, you were Hitler as well as the people that he killed and so on. And I was like, oh, I not only the one doing harm but also being harmed and so on? Am I the politicians that are laying everybody off and also the person being laid off and so on?

story because like it had this idea, thought-provoking idea which is you are everyone and everyone is you. But I'll tell you how that made an effect on me concretely which is that ⁓ I feel a lot of things for a lot of people and ⁓ since I ran into that I figured ⁓ wait what if I'm that other person too you know and so like when I'm running to like at TPAC just last week I ran into like

I ran into a bunch of people that I love working with, they are hard, smart people that are stubborn as hell, and I'm also stubborn as hell. But if you think about them as if they were you, you think of them as like, ⁓ wait, I see where they're coming from, that they're trying something different from a different perspective.

⁓ Helping them is helping myself. So the way that ⁓ I think of this is in terms of rationality and reductionism is that if you think about a cell, like a unicellular life, like a cell at some point duplicates into two with mitosis, and the point of when the cell breaks into two and it's a well-known thing, which one is the original one?

Or are they both the same? Right? Like which one's the original? And if they keep doing that, like which one is the original one and which one's the same? So if you look at life, how life got started, and then if you have all those cells propagating, duplicate, and have kids and so on, which one is it me? And which one is the one that originated me? Instead of like worrying yourself, you're like sitting like in Zurich and I mean, Mounted View, like we're so far apart. But like we can almost trace both of our life choices as something trying different things.

Right? And then as much as I ⁓ can agree or disagree with you, I just feel like both you and I are just the same in that coming from different perspectives. That has helped me actually get work done.

Warren (1:16:30)
you

It's ⁓ very reminiscent of the concept that comes up in... There's actually a character in Invincible, the comic book and show, which is very good, and the prestige, ⁓ it comes up as well, like who is the original. ⁓ And if anyone's interested, the Conway's Game of Life, the little ⁓ cells that are organized by a simple ⁓ equation to drive the next state from the current one, is this idea that every single place in the universe is governed by the same equation.

And there's no fundamental difference between individual cells from each other or different people. So I really like the perspective. ⁓ Always good to bring. I don't think anyone ever said that we needed more philosophy in software engineering. But in case you're just driven by the day-to-day tasks and don't ever get the enjoyment of fighting about variable names, ⁓ here's one more step on top of it of how you actually work effectively. So I love those picks. ⁓

Thanks, Sam. So I guess I gotta share mine. ⁓ I thought a lot before today's episode, and I thought the thing that could be relevant is the platform revolution book, How Network Markets Are Transforming the Economy. It's by Jeffrey Parker, I use it, I think it says a lot of things, like what is a platform? Like a multi-sided platform, and not necessarily like an engineering platform or a development platform. And it shaped a lot of how I think about.

how entities work together or against each other in building a platform with many different-sided entities with their own ideology and what they actually want to do and how to extract value there. It's sort of how I've driven when I understand, like I shared earlier in this episode, that when you have a product and all your users need to do the same thing and it's a not value-added activity, you should question, why are we making the users do that? Especially when all of them need to do that thing. If all of your users need to log in,

or design their own login strategy for the browser, you get a question like, why are we making them do that? Maybe it's you don't have the resources to build every feature known to humankind into the browser so that applications just have a configuration file or a YAML file. But there is really something novel there that I particularly like and it has driven a lot of my thinking around.

Sam Goto (1:18:45)
Yeah.

Yeah for sure. Have you run into the master switch?

Warren (1:18:54)
I've heard of it, I haven't yet.

Sam Goto (1:18:58)
It has to do with platforms and how a lot of them tend to centralize. How centralization, if you don't deliberately try to stop them, it's like the second law of thermodynamics, it would just converge to centralization. It should also give you a sense of the effort, the deliberate effort of having things be more open comes at a cost. yeah, that's a good, did you say platform revolution?

Warren (1:19:02)
Okay.

Yeah, The Platform Revolution by Jeffrey Parker. The link will, like always, will be in the description. Okay. Yeah.

Sam Goto (1:19:29)
I don't think I ran into that. Yeah, that's a good read. But yeah,

I may counter the offer, ⁓ the Master Switch is a pretty good ⁓ platform analysis too.

Warren (1:19:40)
Okay, yeah, I love systems engineering books. Systems thinking really on complex problems and how to make sure the right thing happens. think the self-guiding flame, that's really, ⁓ yeah, for sure, meadows, Yeah, yeah, for sure. Okay, well, this has been an absolute pleasure, Sam. Thank you so much for coming on and talking with us about FedCM and Chrome and your experiences at Google. This has been great. I know you're just here.

Sam Goto (1:19:51)
I'm assuming you're running to Donatello's work. Okay. Yeah, for sure.

Warren (1:20:08)
on behalf of yourself. So I really do appreciate you taking the time out of your day to make this happen.

Sam Goto (1:20:13)
Yeah, for sure. was a pleasure talking to you too. Nice meeting you.

Warren (1:20:15)
Well, thank you.

And thanks for all the listeners for jumping in for this episode, and hopefully we'll see you all back next week.