 Welcome everyone and welcome to the CER Technical Community Hour. Today's topic is Chrome as an independent app on Chrome OS, also known internally as LaCrosse. My name is Rich and I'll be your host for today's presentation. Joining me today, we have our main speaker, John Lucas Stordo, who is a technical program manager with the Chrome Engineering team. Also joining us is Damien Ranzouli. He is a partner engineer with the Chrome Enterprise team, and he'll be monitoring today's Q&A session. For today's agenda, we'll start with a quick introduction of the CER Technical Community Hour program, and after that, we'll jump into our main topic, where our speaker will walk us through the background and call to action for our CER partners. Today's Chrome Technical Community Hour is brought to you by the Chrome Enterprise Recommended Program, which is Google's partner program for third-party solutions that are optimized by Chrome OS or integrated with Chrome browser. The Technical Community Hour is one of the benefits of CER. This webinar brings you the opportunity to engage with our team about new features and updates, enterprise development best practices, and our enterprise strategy. Now, without further ado, I'd like to pass it over to John Lucas to kick us off. Thank you, Rich, and while I'm taking over the presentation, I'll introduce myself again. My name is John Lucas Stordo. I'm a Technical Program Manager on Chrome OS, and I particularly work on what we call the commercial side, which is enterprise and EDU. So you all are one of my target audience here. Today, I'll be talking about Chrome OS in the independent app, and we'll go in quite a bit of more detail in a moment about what this is and why we're doing it and what is happening. But in a nutshell, this is what is happening. This is, first of all, as Rich already mentioned, Chrome OS independent app is what has been called, or you might have heard, called LaCrosse. Previously, this was our internal name for this architectural change that we are making to Chrome OS. We're moving from a state like the current state where the Chrome browser is ultimately embedded in the Chrome OS app, in the Chrome OS story binary to a stage and after this architectural change to a stage where the Chrome browser is going to be an independent app and itself is going to be a component of the Chrome OS platform. Now, before we go in further details about that, I wanted to outline one guiding principle that we are trying to abide to in making this architectural change. This is a change that is designed to be transparent to end users. Ultimately, we expect this architectural change to unlock future evolution of the platform, but by the time we are not introducing new features at launch, in particular at launch to managed users, so enterprise users like your audience. And this is, by the way, also why myself, a technical program manager, is giving this presentation rather than a product manager. More importantly, we are not only not trying to introduce new features, but in particular we are striving not to impact existing and critical user journeys or workflows of our user base. And this is where we get to the main reason for this presentation. We've done, tried to do our work to make sure that that's the case, but we can only be 100% sure that this is the case. We are not disrupting existing user journeys, existing workflows if we verify that your application, our applications and solutions work as intended under the new architecture. So this is going to be the guiding principle and sort of the reason for the rest of my presentation. Now, let's go a little bit more detail in what is happening. As I said earlier, in Chrome OS, Chrome is really an integral part of the OS. And it's actually even more than that. That is, Chrome OS itself is a single binary, a monolithic binary that wraps together a lot of pieces, at least the sum here on the slide, System UI, Window Manager and Compositor, the Chrome browser, as we mentioned, UI toolkits and various system libraries. These are all wrapped into a single binary. Now, this is an audience of developers. You can immediately recognize that such a monolithic architecture introduces certain complications in terms of development and in terms of maintenance and in terms of extension and growth of the platform. There are some that are specific actually also to Chrome OS because Chrome, the browser itself, is a separate product for Chrome OS that is meant to be cross OS platform. So we have Chrome on Mac, on PC and also Chrome OS. And so that the fact that this is essentially an independent piece that that needs to be embedded into the Chrome OS binary creates quite a bit of unwieldy development on our side. So in part, let me be clear, in part these changes have to do with essentially doing a little bit of a house cleaning on our side. But in part actually are meant to unlock new capabilities and new avenues for potential evolution of the Chrome OS platform. Let me give you a couple of examples. So this is where we are trying to move from a stage, again, where the browser was itself part of the OS binary, to a stage where it's a separate application that talks to the OS but is kind of separate from it. Well, there's a couple of things, that a couple of evolution of the platform that are immediately possible once you move to this format. One being that Chrome now not being embedded in Chrome OS. Well, this can be closer to the Chrome that is experienced on other platforms, on other OSs. So users can have a consistent Chrome browser experience across OSs. There are some differences that you might be aware of in the behavior of Chrome on Chrome OS with respect to what are the capabilities of Chrome on other platforms. And people potentially do away with this special custom behaviors for Chrome OS. And another interesting aspect is the fact that once we have the browser completely separate in a separate application from the OS, we're essentially creating a hard boundary between the two that we can actually even harden further to improve the security posture of the OS. For example, the browser being a separate application could update independently, we could allow the user to apply browser updates, browser security updates without having to reboot and things of this sort. Now, let me emphasize that's the reason why I put these things in gray rather than in black. We are aiming not to launch any changes like this at initial rollout of this architectural change. But these are avenues that are opened up once we make this architectural change. So this is actually, this is the change. And, you know, in a sense, we are ultimately taking the browser out of the OS and we are factoring it out there. Now, I use this term factoring it out because I actually want to raise some alarm bells on your side. That is, things look very simple once you're looking at, you know, purple and yellow boxes on this slide. But, you know, you must be aware that refactorings are never fully straightforward. They involve complexity and this refactoring is not an exception. It involves a lot of complexity that is hidden in this, you know, pretty boxes slide. So let's look a little bit more at the flavor of complexity that we're dealing with. First of all, the reality is actually some more complicated. It's not like that we just have a browser that talks as one communication going to the OS, like one arrow going to the OS as in the previous slide and another arrow going back to the browser. But the browser itself is a collection of capabilities. And a collection of pieces that talk in a very complicated way with pieces of the OS. Now, I highlighted there in dark some that are relevant to the change that you're making because ultimately, now we're taking this browser out of the OS and get into something like this. Once you see this, immediately notice, oh, there is a lot of connections that need to be rewired. A lot of rewiring that needs to be done. Well, having to redo this rewiring, I get to raise another alarm bell on your side because you can see here that while earlier we had a lot of arrows that a lot of pieces that talked to each other within the same blob from once. Now we have pieces that talk to each other across the boundary. I said earlier that we have created a boundary between the browser and the OS. Well, we need to do all this rewiring in a way that maintains the behavior that existed before we made this architectural change. Now, the good news about this is that we've done the work. So let me go here for a second. We've done the work to port the Chrome APIs. So in theory, there should be no work left for your developers. Your applications should work under the new architecture as they work under the previous architecture. But as I said earlier, this rewiring, this refactoring involves complexity. And every time these type of changes need to be made, some bugs might creep up. And that's the bad news, that porting some of these APIs was definitely not straightforward. And you can also understand why, because in some cases, take as an example file system APIs, a conversation that happened between the browser and the OS within the boundaries of the OS now has to cross the boundary between OS and browser. So as I said, there have been various APIs whose porting has proven to be more complicated than or less straightforward than completely transparent and completely easy. Of course, your applications might be using some of those APIs. So definitely that would give you an incentive to look at your application and verify that their behavior under the new architecture is the same as the behavior under the previous architecture. But this applies in general. Even APIs that were easy to port required making some code-based changes that, worst case scenario, could have introduced some tricky bug, very hard to hit. But when it's hit, it might just affect the user experience. Also, another thing that I should mention is that, again, some of the interactions between browser and OS that earlier happened within the same application, within the same binary, now are interactions, ultimately messages that are exchanged, possibly a couple of times over between two different applications, two different processes. That means that potentially the timing of certain operations might have slightly changed. So if your application is very dependent on the current timing of certain operations, this should be a strong invitation to verifying that the behavior of application is not affected under the new architecture. Also, another thing is that the keen eye among you, I might have noticed from this slide, is that actually there's two browsers. And so there's still a browser left within Chrome OS, in addition to the new Chrome as an independent app browser. The reasons for that is partly technical. There are certain OS surfaces that need to be rendered. And we are basically for the time being, we are taking advantage of the rendering bits of the old browser in the OS binary. But also that allows us to have what we think is a smoother or less whiskey rollout of the new browser. Because if we still have the old browser there, the possibility arises for a user that encounters a blocking issue, a remaining blocking issue. Once we moved our user base to the new browser, to revert to the old browser and be unblocked without having to roll back or update the OS on their devices. So this is nice for us, because essentially it enables a safer rollout, but also there might be situations where both browsers are running. And that potentially means that usage of the system resources might be higher. So again, if your application already by itself tends to stretch the limit of the resources available on certain types of devices, you might want to verify that there is no performance issues once we move to the new architecture. Now I've said, told you something about the what and the why. And again, let me get back to essentially nutshell, we are making a large change and we are trying to make this transparent to users. I forgot to mention this earlier, but a metaphor that I'll use often when I give this presentation is that we're ultimately trying to change, do something like changing the tires of a bus, while the bus is in motion without the passengers noticing. It's a tall order. It's a tall goal. We're trying to do something that is pretty hard. So the question is like, how are we going to do that? And that gets us to the how and when. Well, we're going to do this very slowly. We're going to take time to do it. We're going to do it very deliberately. The idea is that we're going to start the rollout of this new architecture later this year, but we expect the rollout to run well in 2024. The idea is that once we make the new architecture generally available for customers to try it out, there's going to be an extended amount of time for them to just try this out on an opt-in basis in order to verify that things work for them. We expect this opt-in phase to last at least six months. Then we expect for the following phase where we essentially flip the defaults. The new architecture becomes a default. However, customers who might encounter some issues still have the option to revert back to the old architecture. This is one of the reasons the possibility that I said was enabled by having the two browsers in the previous slide. This phase where essentially the default is the new architecture, but there is an escape hatch to go back to the old architecture. If problems are encountered, we expect to last at least another six months. As you can see, from the time when we make, when we start this process of rolling it out, that's going to be at least one year until we get to a point where the new architecture is the only game in town. And the plan, of course, the goal here is to use this time to address any remaining issues before the old architecture is retired. Now, as I said, we are starting this later in the year. So why am I here now today talking to you? Well, the reason for that is that we are allowing select customers and developers to have access to the new architecture already now. The idea is that we use this time already now to test workflows and applications against the new architecture so that we can identify any remaining issues and work early together to fix them. Now, as I said, this is happening now and this is my call to action and my request for you developers to get an early start and test your applications under the new architecture. In addition, this is also my request for you to start considering this new architecture as part of your regular qualification testing of your applications. Meaning, if you regularly test your application against new versions of Provoas, please start testing against this new architecture as well. Let me repeat again what the goal is here. The goal here is to change the tires of the bus without the passengers noticing. So the success for your testing should be that everything works as normal. Your users would not even notice that something has changed. Here I have a link to a form. There's also a QR code for those of you who have a cell phone handy that allows you to submit your domain for inclusion of what we call this trusted tester program that gives you early access to the new architecture and allows you to test your applications against it. Please, please join this trusted tester program after joining it. You'll receive detailed information about enabling the new architecture testing against it and most importantly, reporting issues to us so that we can work together to address them. So wrapping it up, a large, large architectural changes are coming to Provoas starting later this year. As I said already, the nature of the change is architectural. We in particular don't want to users to notice. And the reason I'm here right now is that of course there is always some risk involved in making those changes and we would like to involve you right now in helping us verify that your apps and user workflows are not affected. So again, again, please sign up for the trusted tester program. The QR code is repeated on this slide and that's really all I had. So I'll hand it back to Rich to wrap it up. Thank you John Luca for that awesome presentation. Please visit the Chrome Enterprise Developer Website for additional information to supplement your learning. That concludes today's presentation. We look forward to seeing you at the next webinar. Thanks for joining and have a great day.