 Welcome to Ask Chrome, the Ask Me Anything panel with the Google Chrome leadership team where we're answering your questions about troubleshooting, building great web experiences, and the future of Chrome and the web platform. And some of these questions are spicy, so definitely stay tuned. We're also taking live questions on Twitter, Discord, and Slido. You can find the links to Discord and Slido on the CDS website. And if you'd like to ask your question on Twitter, tweet at ChromiumDev, that's at ChromiumDev in one word. We have Jake Archibald looking out for your questions live, so if your question doesn't get asked, just blame him. I'm Nina Kraviz, a developer advocate on the Chrome Web platform team, and here with me we have directors and leads from product management, engineering, privacy, capabilities, rendering, and graphics, all across Chrome gathered here today in a meeting at the same time. And I've seen how packed the schedules are. It's so nice to have you all here with me today. So to get started, I'd love for you all to introduce yourselves and tell everyone watching a little bit about what you do and the areas your teams cover. Maybe we can go in order starting from Ben Galbraith, and then we can go to Ben Goodger, Parisa, and Chris. Great. Hey, everyone. Ben Galbraith. I lead product management for Chrome's web platform team, and I've been working on the web platform or building on top of the web platform as a web developer since, I guess 1995 or so in various industry roles, and I've been at Google since 2015 with one-year intermission. Happy to be here. Hey, I'm Ben Goodger, and I lead engineering, product, and developer relations for web platform in Chrome. I've been working on the web since the mid-1990s, initially as a developer, and then I got involved in building browsers. And it's always been so incredible what people can do with the platform, and as the platform has gotten more powerful, we really see what the future of computing looks like. So I'm excited to be along for that, right? Hi, everyone. My name is Parisa Tabriz, and I'm currently responsible for the Chrome browser product engineering and design team. I've worked on Chrome for about eight years and first joined to head up the Chrome security team, and so care really deeply about security, privacy, and in general, building great experiences for users and developers on the open web. And I'm Chris Harrelson. I'm a software engineer on the Chrome team. I've been here on the team for about eight years. I lead the rendering team, which is the team that does how you turn HTML into pixels, and the rendering NG effort is one of the things that I was helping to lead. I'm also a Blink API owner, and I think I haven't been working on the web since as long as the two bends, but I've been using the web since the beginning, and I love it, and I hope that it gets better over time. Thanks. Thank you all for those intros and for being here. As I mentioned earlier, some of these questions are pretty spicy, so I think it'll be fun to just dive in and get started with some of the spiciest ones. So our first question is around privacy initiatives and some recent news headlines, and this comes from Jeremy Keith, who asks, given the core proceedings against AMP, why should anyone trust Flock or any other Google initiative ostensibly focused on privacy, and for those who aren't aware, Flock is Google solution for ads without third party cookies and individual tracking. Yeah, you and I can take this. So first off, can't comment on the AMP legal proceedings, of course, but yeah, speaking about Flock, Flock, as you probably know, is part of this broader initiative that we call the Privacy Sandbox, and I think it's important to note that we're not asking for blind trust with the sandbox effort. Instead, we're working in the open, which means that we're sharing our ideas while they're in an early phase, we're sharing specific API proposals, and then we're sharing our code out in the open and running experiments in the open. And in this process, we're also working really closely with industry regulators, you may have seen the agreement that we announced earlier this year, jointly with the UK's competitions and market authority regulator, the CMA, and we have a bunch of other industry collaborators that are working with us. So we'll continue to be very transparent moving forward, both in terms of how the sandbox works and its resulting privacy properties, and we expect the effort will be judged on that basis. Thanks. Yeah, thank you. So we also had a lot of questions around AMP and Chrome's plans for it, and these were some of the top voted questions that we got on the Slido. So could you also speak a little bit about what the future status of AMP looks like? I think I could take this one too, Yuna. From the Chrome team's perspective, we view AMP as an important part of the web framework ecosystem, as appear to other popular web frameworks, and we'll continue to support the developers that choose to use it. I also want to highlight, though, one of our goals with the Web Vitals initiative is to make it easier for developers to understand how to achieve things like fast perceived page load times and stable page layouts, regardless of the web framework that they choose to use, and to align Google search with those guidelines. And this was based on feedback from developers based on AMP and the role that it plays in the ecosystem. Yeah, so another thing that we've seen headlines about recently is Photoshop, another Adobe design programs in the browser. And as somebody who works in UI, this has been so cool to see all these integrations, but we have an anonymous question here. It says it's great to see Photoshop on the web, but isn't this just another example of a Chrome-only web? Why doesn't this work in Firefox and other browsers? Maybe, thank Gidry, you could speak to this. Yeah, I'd love to speak to this one. And I think this is an important question, so thanks for asking it. But as we look at the way that the web evolves and the way the web has evolved over the course of history, it's actually relatively rare for APIs to emerge simultaneously in all browsers. And so part of the process that we undergo as we work forward on building the future of the web with the community is to try things out, to experiment, understand that we will iterate. Ben mentioned this before when talking about the Sandbox APIs, but we do all of this very much in open. And we want to just get out there with some ideas. And with the Photoshop launch, you can really see what's possible when we build together a more powerful web. And so I'm fully anticipating that we will continue to iterate on these APIs. We really welcome cross-browser dialogue on the shape of those APIs. We anticipate making changes to them as we figure out ways to make them a durable part and ultimately for them to become standards. So yeah, that's our view. A very open process, a very collaborative process, but it starts here. I also just want to jump in and add that Adobe has publicly shared their intent to bring Photoshop to more browsers and is working hard with other browser vendors. And also note that a recent tech preview of a future Safari release included support for the File System Access API, which is one of the APIs that Adobe needs. That's great to hear. So just in general, is browser diversity important to you all? I think I can take that one. This is a topic that is near and dear to my heart, so I appreciate the question. The short answer is that browser diversity is actually quite important because the web is an open, interoperable, and universal platform. And browser diversity is part of what makes that stay the way it is going forward. Competition paired with a commitment to interop is also a good thing as it helps to make sure that the web stays and keeps getting better over time through those operations. And this is actually one reason we also have efforts like the one that Compat 2021, which was mentioned earlier, in order to increase the interoperability of browsers going forward. And actually I have even more good news to share, which is that the score for Safari on Compat 2021 has increased since we created the slides for the keynote from 85 to 92, so progress is really fast. Wow, that's awesome to hear. As somebody who builds the web and runs into interop issues, it's been great to see browsers working together to get some of these key APIs normalized so developers can use them faster. Yeah, I was just going to add to what Chris said or maybe emphasize it because he said it, but I also feel like competition is just so important for innovation. And so even though most of my time is very much thinking about how we can build the best Chrome browser and Chrome browser experience, I really think that it's exciting to see how many browsers are sort of emerging and what innovation comes from that. And so I'll chime in as well to say I think it's pretty important. Yeah, I love that sentiment about innovating and also working together to bring a better web to everyone. That's definitely key. So Carissa, I have a question for you here. This is just around the review process for extensions in the Chrome web app store. There are some complaints that it's rather long, it takes a week or more. What steps are you implementing to reduce the review time? Good question and feedback. Thank you for the feedback on that. So the whole developer experience for extensions is super top of my interest and for sure the review process is one piece of that. We continue to invest in it and try to improve our policies, clarify those policies and also make our review process more efficient. And something me and my team look at are kind of mean and median review time and sort of what's happening at sort of the exceptional spaces. So I know over the past year we've actually been able to review the average review time for submitted extensions to where now even pretty complex extensions are reviewed and approved in a couple of business days. And I think we're always trying to improve that. And at the same time, make sure that we are really keeping the quality bar and the safety bar and the privacy bar really high for extensions so that end users can have confidence that something they get from the web store is really high quality. And so thanks for the feedback. We continue to work on it. Proud of the team's progress in making things more efficient. But of course, there's always constantly trying to improve that experience. Yeah, thanks, Risa. So we saw on the keynote that there are a lot of awesome features launching and we got a live question in from Ronier on Slido with all of these awesome features, the future of web browsers will be, will the future web browsers be in a place or a place IDE? Could we develop our apps maybe 80 or 90% entirely in the browser? Is that something that you see? Happy to take this. I've been enthusiastic about the web IDE space for a long time. I worked on a project doing this in the late 2000s at Mozilla. I think we're seeing the capabilities of the web expand dramatically. And moments like the Photoshop preview we talked about and so many of the other powerful apps that are on the platform showcase what's possible. I don't know that it's about replacing conventional desktop IDEs. I think there's room for a lot of different approaches. But I would expect in the coming years to see more and more people able to do their full development cycles using the pure web-based IDE. And I'm really excited about that. And I can't wait to see it. Yeah, I could definitely see that future becoming more and more of a reality as well. So speaking about browser diversity, which is we talked about a few questions ago, another popular question that we had was around mobile browsers. Remember, here's the question that comes from anonymous. Were iOS comprises more than 50% of devices? What's the future of the mobile web without real engine choice? How does one, how does the web stay competitive without Apple on board? Yeah, I can jump in and start to take this one. So on the Chrome team we think it's super important that browsers are responsive to the needs of their users and their developer community. And so that, for example, drives the investments that we make as a team. We work on performance because users tell us they want the browser, they want the web to be faster. Developers tell us that they want new APIs, new features, they want us to fix certain bugs. And so we prioritize that. If you've been around for a while, you'll remember an era on the web where innovation slowed down and even stopped when there wasn't enough development on the browser, on the platform. And what got us out of that funk, really, was the ability for users to make choices about the experience that they want to have. And so that's super powerful. Parisa talked about competition and why that's so important. We believe that super strongly. It's important that users have the choice and then across browsers we can think about how to make a better product for users and how to respond to our developer community effectively. So those are the principles that guide us. Yeah, I totally agree with what Ben had to say. I just wanted to add a couple more points. One is that I don't think iOS is 50% of devices worldwide. I'm always surprised at the diversity of devices and platforms out there. But regardless, it's totally true that the Chrome team supports an open web and that's why we work extensively in the open to support the web's success. And an important part of that is a diverse set of browsers across all platforms, including iOS. Definitely. So we also had a few questions about Manifest v3. Is Manifest v3 compatible with all versions of Chrome or at least which versions are covered? I can take this one. So Manifest v3 was available to use since Chrome 88. And so it should be compatible, all versions after that. We just shared an update on our timeline for deprecation away from Manifest v2 a month ago. And that's going to be the progress as we evolve the extension ecosystem to Manifest v3, which has lots of security, privacy, performance updates. The faster people can move to Manifest v3, the better. And so please do that work where possible. And on all questions related to sort of extensions in Manifest v3, we have Chromium extensions at chromium.org as a really good place to engage with kind of all specifics. A follow-up to that question. Why is Manifest v3 taking so long? Yeah. So I touched on it just like a little bit, but it's been important for us as always when you make these big changes to really listen to the developer community and get their feedback on improvements, get their feedback on what's working or what they need. And so part of the reason this transition has taken a while is really to make sure that we're hearing all those voices, acting on that feedback and giving developers time to make these updates because we don't want to break a ton of extensions who are on Stull v2. And so I would love to go faster, but also because there's just a ton of improvements in Manifest v3 and at the same time recognize we have to be thoughtful, especially in sort of complex times to make sure that people have the time and space to make the updates they need to their extensions. And so I'm also eager. Thank you for the question. And one of the things we're committed to doing is to just really keep providing updates on timelines because we will deprecate v2 and want to just make sure we can do it in a minimally breaking way. Yeah. Thanks, Parisa. I really like this next question. It's a little bit more general. What are some examples of proposed web platform features that the Chrome team has declined to implement and what went into that decision? I think I can take this one. And apologies in advance that my answer is a little bit long, but I think it's because it's a complicated question. So as I mentioned in the beginning, I'm one of the I'm the lead Blink API owner, which means that I work to help approve shipping new features in Chromium. So let me tell you about how that works and how it differs from Chrome. So Chromium and Chrome are not the same thing. Chromium is an open source project with contributors from many companies, such across across the board, such as Microsoft, Igalia, Opera, Samsung, and so on. Chrome is Google's product that is built mostly on Chromium. And distinction is important for questions like this, because when we implement a feature, the feature goes into the open source project, whereas Chrome is like a shift product that builds upon that code base but could potentially have differences where we flag features on and off. So let me give you a couple of examples of features where Chrome decided at the moment at the time or at the moment that it wasn't the top priority to implement the feature, but it was implemented anyway because someone else contributed it. One example is MathML, which will when it ships hopefully sometime soon will allow all websites to have easy to express mathematics. And that one was actually contributed by Igalia. So while Chrome didn't feel like it was a top priority to implement that relative to other features at the moment, the code was reviewed and was added to Chrome. Another example is the request storage API, a recent one that Microsoft is implementing. Again, that's being implemented in Chromium. And there are also a few cases where the Chromium owners, meaning like the code owners, the people who try to make sure that the code base is high quality and sustainable over time, have decided that there's too much complexity and that it would be too much of a difficult feature to implement at this time or as designed. And one of those examples is CSS Regions, which is one that was proposed a number of years ago and was ultimately removed from Chromium. So after a feature is implemented, it may be shipped in Chromium, which means that we go through this Blink API owner process and then we turn it on by default. And that is done as long as it meets the requirements of building towards a standard-based, open, interoperable web platform via consensus specifications. And that process, as I mentioned, is mediated by the Blink intent process and the API owners. However, Chromium-based browsers like Chrome, Edge, Opera, Samsung Internet and so on can and do actually flag features on and off, which are in Chromium by default. So hopefully all of that long-winded explanation helped explain our point of view towards Chromium and Chrome. Thank you. Anyone else want to talk about features? Presidentship? All right. Well, we have a live question actually that builds on to this from the other side of the coin about specific features that maybe you can also answer some, Chris. Are you planning to implement CSS subgrid? Firefox is currently the only browser that supports it. This is another good one. So originally the grid implementation was contributed by Igalia also. As you can see, Igalia is actually a really important contributor to Chromium. And that was added to Chromium because we just didn't have the staffing to implement ourselves, but now we've actually reimplemented it as part of the LayoutNG project, which is part of rendering ng. And this new implementation is actually a much higher quality basis that we believe will be straightforward to add subgrid to. So that is actually starting implementation right now and it's being implemented by Microsoft contributors. Thank you. I'm very excited for that feature as well. So I have a question for you, Vengager. Is the Play Store and Android app compatibility still a priority for the ChromOS team? Development seems to have slowed right down and API level lags on phones, or lags phones. This is from random Android Dev. Yeah, no, it's still very much top of mind. Playlisting, for example, recently have improved support for billing with entrusted web activities. Trusted web activities also provide a really convenient way to encapsulate your PWA in an Android environment. So yeah, that has been and continues to be very much top of mind for the ChromOS team. As a platform team, we are very much focused on trying to build a more powerful platform that enables cutting edge app experiences, especially on Chromebooks. Sometimes that has us working on the Android integrations, the playlisting components. Sometimes that's us working on advanced runtime technology or new web APIs, like some of the stuff that we've talked about with Adobe and so on. And so, really, if there's something that you feel that we're missing, we encourage you to just reach out and let us know. Great. So we also got a few questions about Lighthouse and how benchmarking is handled inside it upon. This one comes from Adriano S. What's the plan with Lighthouse and the Moto G4 slash 3G connection benchmark? Is this device, network combo still the global average after so many years? That's a good question. I can take that one. So yes, it actually is. And this is related to my kind of caveat point I added to a previous question about iOS where actually there really is a really wide variety of devices. And it is true as far as we can tell that a device similar to Moto G4 3G in its capabilities is representative of the global average. So that's why we have it in Lighthouse. And if we see that change through our analytic data, we will definitely update Lighthouse accordingly. And just this is a good reminder that there is a tremendous amount of diversity of devices and network speeds out there. So it's really important to make sure your site performs well on as many as you can. Thank you. Another benchmarking question is about time to first bite. This one comes from Walter Lee. How do you count time to first bite in crux? For example, if the site has many elements inside of it, do you just count the first HTML time to first bite or average it all out? The core web vitals are quite complicated and subtle areas. So this is a really good question to dig into. So time to first bite, sometimes called TDFB, means the time from when the user requested navigation to a site until we get the first bites off the network. So it's actually even before we parse the HTML. It's when you get the first bites back into the Chrome browser. And another point to make is that this covers just the main page resource and not sub-resources such as images. Okay, thank you. So we had another popular question that's a bit more broad, but this question is how deeply will Chrome be integrated with other Google projects? I can talk about this one a little bit. It's a great question. It is hard to add on the abstract, but when you think about Chrome, it's Google's browser, Chromium browser, and we try to bring the best browser by Google as a high level of what we think we're trying to achieve. For me, it always goes back to what are the key user jobs or user journeys or developer jobs that we're trying to serve with a browser? Search is a huge one for a web browser. Doing complex work, whether that's research or learning or in my case, doing work across many different tabs with collaborative docs and email. So complex journeys, shopping. We think about seeking out information and consuming it, and that can be like entertainment or kind of long-form reading. So we always go back to what are the user journeys we're trying to solve. And then we have this amazing Chromium project to build a browser on, and a lot of other things at Google. Search is the one that usually comes to mind. And as search is innovating and continuing to evolve how that technology and those products can work, we think about how can we really bring that to Chrome. So earlier this year, we announced that we're bringing Lens, which is a visual way of doing search into Chrome. And we think that that can actually be really useful for shopping or other user journeys where visual search as a new input modality than just sort of text input can be important. And so there's not like a specific number or proportion I can talk about, like where we think about bringing Google innovation and technology to Chrome. But it's something we're constantly thinking about related to search and shopping. For me, security is also top of mind. And safe browsing is a Google security technology that we integrate deeply into Chrome to protect people from going to sites that will fish their data or install malware. And integrating with a Google password manager so that we can actually make it easier to generate strong passwords and manage them and remove just some of the hard edges and insecure properties of passwords today is something we're working on. And so other security and privacy features, as well as just kind of a whole host of things, but always rooted in how we think we can improve the user experience and with an eye towards kind of other great things that are happening in Google that we can bring to the product more so than any specific number or metric. Yeah, I love that. So on that thread, speaking of user journeys and user requests, we got a question from MTom. Is anyone on the Chrome team looking at building and implementing a Web SQL 2 spec? If not, can we formally request or get involved? You and I can take this. So we've learned a lot over the years through Web SQL and IndexedDB and just in general our efforts to build and structured storage into the browser. We're investing our efforts now into something called the Storage Foundation API. And this enables JavaScript developers or assembly developers to implement high performance file IO directly on the Web platform itself. And when you look at the challenges involved in having a browser own and maintain a sophisticated storage system like a SQL engine and to keep it optimized and bug-free over time, we think enabling this at the library level makes a lot of sense. And I'm really excited to see what the ecosystem builds on this. Yeah, cool. So this is another live question. This one comes from Stacy via Slido. Stacy says, hi, I made my own website through WordPress. Awesome. What are the most important things I need to do to make user experience the best it can be? Actually, I have just one thing to say on this. First of all, we love WordPress. We have a WordPress plugin that we create called Site Kit. And Site Kit has our best guidance and utilities baked right into it. So all you have to do is search for Google Site Kit and take a look. Nice. Any other tips on UX? I don't have a huge number of UX tips. I do think Core Web Vitals is a huge part of our guidance here. And Site Kit makes it really easy to measure your site on Core Web Vitals and to get concrete tips on how you can improve Core Web Vitals scores. That's a great starting point. Yeah, data-driven UX right there. So here's a question from Nicholas Mendiz. I haven't heard about the Portals API for a while. Is it being abandoned in favor of the Web Transitions API? Maybe, Chris, you have the answer for this one. Sure, yeah. I actually do have a lot of context on that because I'm one of the people who's helping to develop this shared Element Transitions API that I think is what the question is referring to. So Portals is not abandoned. We actually prototyped it in Chrome YUM. And we discovered that actually while it's a great feature and it has a lot of promise, in order to implement it in a secure, private and reliable way, we actually needed to invest a bit more in the underlying technology. Like basically by underlying technology, I just mean like the code in Chrome YUM needed to be refactored in a lot of ways so that we could support showing render processes and web tabs in this new mode that is different from Portals to other things. So actually it turns out that that same underlying technology will power not just this feature but things like pre-rendering, another feature that we're working on, Back Forward Cache and Privacy Sandbox Features. So we're doing all that investment right now, but it's going to take a while to complete. In the meantime, we're investing in approaches that improve the user experience over time, but are a little bit simpler and perhaps easier to it, or hopefully very easy to adopt and share Element Transitions, which if you don't know it, is about allowing nice animations to occur automatically during page transitions for MPAs and SPAs. So we're doing that and we think that it will pair well in the future with Portals when we're done with that infrastructure upgrade. Thank you, Chris. So this next question is a little bit meta, but we've been talking about this idea, you know, the web platform. This question asks, how do you define the web platform and how has that definition evolved over time? Okay, I could start with an attempted answer. First of all, it's a bit tricky to define because the web is not just APIs and it's not just browsers because if you just have a browser but there are no websites and there are no servers to serve content, what's the point of the browser? So if there's an ecosystem here of interdependent websites, there are ecosystem affecting products of many kinds like frameworks and the search engines themselves. So all of this together is what we think of as the web platform overall. However, at its core, of course, there is a system of open and interoperable browser and client-side APIs that the whole thing is built on and allows different parties and companies to interoperate smoothly with each other. And so I don't think that particular definition has changed over time, which by the way, I would say is an amazing testament to the quality of the original idea of the web. Pretty amazing idea. But it is true that these APIs are constantly improving and increasing and the capabilities of websites are increasing over time. So in that sense, the web ecosystem is growing and defining its new roles in many new ways. For example, the IDE question, like 20 years ago, web IDE, okay, maybe in the future, but now it's a reality. So that's my answer. Yeah, I just want to build on that if that's all right. I agree with Chris's definition. I think it's similar to how, believe it or not, how we think about the body in a sense, because when you experience life, where do your cells and your DNA end and where does the role of bacteria that you're a host for begin? And I think the web platform similarly, because it's emergent based on all the browsers that are available and that people are using and the libraries that they're using on top of it and the frameworks that are used on top of that and the third-party services that are incorporated into the web experience. And all of this goes into what I really think is meant by the web platform and how users experience the web platform. It's a fantastic, open, organic, and constantly evolving platform. Oh, sorry. I just wanted to add one really quick point, which is that, like, Ben, with something you said, trigger something in my mind that I think is important to mention that on the Chrome web platform team, we really think beyond just Chrome, which is why we're talking about core vitals for sites generally, which is why we're talking about compact 21 scores across browsers. Because while the main thing we're doing is building and shipping a browser, the whole ecosystem is much larger than that. I'll add on, I've used the term beautiful chaos to describe all of the innovation and activity that started in the 1990s and has been exploding since. And I think Chris is right. There's some things that are static. There's some fundamental principles, properties that were baked into the platform from the beginning. Things like openness, things like low friction discovery, things like reach. When you have multiple user agents implementing that set of open standards, those are all really powerful things. As we look at the platform, we're trying to find ways to understand those, reveal them more, to emphasize them more and help developers build amazing experiences. And so I would really say, as we look forward, understand what those fundamentals of the web are. And then where do you want the web to go? This is for the developer community. This is for the community around the web to decide and chart that course. I have a reaction. Sometimes I see these people pontificating along the lines of, oh, hey, the web should only be about this one thing. Maybe it's only a document viewer. It shouldn't be about apps. Well, ever since the advent of web mail and search, we've had services and application experiences on the web. So I don't think you can really say it's not about those things because it is. And so as developers, just continue to step forward, contribute, share your ideas, share your experiences. Let's continue to make this a super awesome platform. Yeah. It's been amazing to see how far the web has evolved while staying true to its principles. I think you all for your answers are great. We got a question from Simon Bloom. Are there plans to reduce the numerous and repeated permission prompts for PWAs and progressive web apps? Permissions should be grouped and remembered for installed PWAs. Question and feedback. Yeah, sure. I can jump in on this one as well. I know that, you know, we're still, you know, as we've added like a number of really exciting, powerful capabilities to the web, we do feel a bit of attention around both the demand to add those capabilities and like how do we explain these reasonably to the people that are using the software and how do we make sure that we don't overwhelm them with too many requests and so on. The challenge here is really finding the right settings on the dial of like how much to show. You know, we could say, well, just ask when it's appropriate. Well, what does that mean? Like this is something where we are actively studying like what for certain capabilities, when is the right time to ask? What does that look like? And so we're doing, you know, like instrumentation analysis and study. It's a journey. It's something where I feel like we will make progress, you know, over the next, you know, year or so. But it's definitely a hard problem, but something that's top of mind for us. Thank you. There's also a few questions coming in asking around, you know, why can't we put PWAs in a play store similar to what we see Microsoft doing with Windows? And here's a question that says, a couple of years ago, Jake asked this very panel, when are PWAs going to be listed in the play store? When are they going to be listed in the play store? I'll take this. Benji spoke to this a little bit earlier by the other Benji. You know, this is a complex space in my view because you've got the stores which are owned and operated distribution channels with policies that they have for the content that's in them. And then you've got the open web, which is open and available to all. And so marrying those two is tricky. And we have technology, we call trusted web activities, or TWA, which enables developers to distribute their web content in the Google Play Store on Android and also on Chrome OS. And we have tools like bubble wrap that make that process streamlined and relatively simple. And this is currently our approach. Appreciate feedback. And we're constantly listening to developers and looking at ecosystem developments and evaluating our stance. Nothing new to add. Thank you. We got a live question here about CSS Houdini APIs. When will the CSS Houdini APIs for layout, parser, and font metrics be ready to use in Chrome? Chris? Sure. I can answer that question. For layout, we actually decided that we could not properly implement and ship the layout API until LayoutNG was done. So as I mentioned in my rendering, NG blog post, LayoutNG is coming to a close now-ish. It's actually probably going to take until a little bit next year. And after that, we're going to come back to the layout API. And the other two were font. And what was the other one, Yuna? The other one was parser and font metrics. Layout parser font metrics. So for font metrics, we've been gradually introducing additional font metrics directly into the platform. And I don't think there's a particular plan for a parser Houdini API. Okay, great. We had another question about cross browser capabilities. Firefox and Safari are implementing privacy features like cross-site isolation. Why isn't Chrome doing the same? Maybe, Parisa, you can have some insight on this. Sure. So let's see. Digging into this question. Well, first, Chrome is super committed to advancing security and privacy on the open web. It's a personal area of commitment and something I'm really proud of. The work Chrome has done over the past decade plus. And certainly, there's lots more work to continue to do here, both in the product and the platform. When it comes to site isolation, so Chrome launched site isolation, which is a security feature a couple years ago, and that advances protections via sandboxing at the site level. I'm not sure if that question is referring to that, but that's something that we're seeing other browsers actually pick up. Now, in the privacy space, and perhaps this question was talking about privacy and anti-tracking, we're seeing also innovations and different approaches to combating this problem. Chrome has a privacy sandbox effort, and what this is a collection of APIs and features that are all intended to advance privacy on the open web, but also ensure that we're supporting really vital use cases for developers in particular. And a bunch of features, you can read more about it at PrivacySandbox.com, and I know we have some sessions on that at Chrome Dev Summit. Just one feature that I know is an active development is called fenced frames. And what that is, it's a type of iframe that is more privacy protected from the actual containing page. So that's just one example. But broadly, we invest a ton in this space and very much depend on feedback from developers to make sure that we're advancing things in the right way, and also your support in deprecating APIs and technologies that we think have been replaced by improved APIs too. And so thanks for the question, and look forward to continuing to work together on improving privacy on the open web. Thank you. Our next question comes from Lauren. Do you feel the move from web fundamentals like vanilla development towards external ecosystems, which as React is concerning? How many turtles must we stack? I could start with trying to give an answer. It's a good question because there are so many frameworks, so many libraries out there. And then as we mentioned throughout CDS this year, there are tons of new web APIs too. So from my point of view, if you're using a library framework and it helps your web app perform well and succeed, that's great. Success and a useful website is really the most important thing. That being said, the more turtles there are, the more complicated it is to make all the turtles not fall off of each other. And there are definitely performance challenges that are inherent to loading and executing more scripts because the more bytes that you download, the more JavaScript you're running, the more that VA has to figure out how to run it quickly. So less is better, all things being equal. That's a key point. All things being equal. The library adds a lot of value. That's great. So however, we're undergoing a continuous process of identifying the common things that a ton of sites want to do. And if a lot of sites want to do a thing, then we should consider adding it as a web API or whatever that thing might be. And so over time, we might add more web APIs and then that would reduce the need to download additional JavaScript to do that same thing. So I just want to pick up and add to what Chris was saying because I think it's a really fundamental strength of the web platform and the web ecosystem that we have this constant innovation in the frameworks and libraries that are available to build. And it can seem a little exhausting sometimes because every time I turn around, there's some new approach. But at the same time, I think this pushes the platform forward in a powerful way. And Chris was talking about what I think is the spectrum that we've been facing in computer science and software development from the very beginning, which is developer ergonomics on one side and runtime efficiency or performance on the other. And it's not really clear to me that there's an objectively right place to be in that spectrum. I think it's a very individual decision based on the teams and their goals. But what we are trying to do with the Web Vitals program is provide objective guidance to the ecosystem on what makes a really high quality web experience for users and to let developers measure their experience regardless of the framework they use and then make their own decisions. Yeah, thank you. So we are coming to the end of our session and I want to make sure that everyone who's watching this session leaves with some next step. So I want to ask all of you, maybe we can go in order starting from Ben Galbraith over to Chris. If developers have a spare hour after the session, what should they go and look at, whether it's a feature API or article or even something else? Yeah, thanks, Yuna. And this has come up a bunch. But I'm a big UI geek. I've been building user interfaces with a variety of stacks for most of my career. And so I am beyond enthusiastic about the Rendering NG project and everything that's been unlocked through it. So I'd encourage you to look at a series of blog posts that our own Chris on this panel made about Rendering NG. And also, Yuna did a great job of talking about what she and others call this new responsive, which is rethinking how we build web UIs based on these new primitives. And I encourage you to study both her remarks earlier this morning and also broader videos and talks that she's done and others have done because there's so much that's possible on the web now from a UI perspective. And it's really exciting to see. Yeah, thank you. Yeah, and plus one to all of that, you know, that's super exciting. I would say, you know, across the content that you see here with Chrome Dev Summit, as well as everything else that you can read about the powerful capabilities that the platform has grown over the years, what I would say is like, as you reflect on, for example, the Photoshop demo that you saw before, the Kapoeng demo that was in the keynote, there's this really powerful thing that comes when we take our conventional idea of what an app is. And then we marry that to this idea of frictionless discovery and distribution through the web, through links, through URLs. And so I would without saying like a specific API, I would just say like, think about the where the web is now all of the amazing capabilities that it has across UI, across runtime performance and APIs and so on. How can we make truly special experiences that are easily shareable that bring people together? That is that is I think the thing that I am most excited about right now it's a unique strength of the strength of the web. And so I'd encourage you to think about that. Yeah. Oh, lots of things. So hard to pick one. I think if BGaulbs or Ben Galbraith is a UI geek, I'm probably a security geek. And so maybe really tactical would be to check out the issues tab on Chrome DevTools and the security panel. And it's so important to fix these issues because I think, you know, Ben Goodger talked about like evolving the platform and pushing it forward. And part of that is really making sure that we can knock it kind of held back by legacy. And part of that is really like graceful deprecation and pushing things forward. And so it's been amazing to see, for example, the push towards HTTPS adoption. And we have like an HTTPS first mode and more tools for developers to like fix those issues. But I would say check out the issues tab in DevTools security panel. And, you know, if you have no issues, then that's a very quick call to action. And if you do have issues, then maybe that gives you some things to focus on fixing and addressing. Thank you. Cool. And if you don't mind a self plug, the feature I'd like you to go check out is called content visibility. And I'm actually the one who kind of came up with and led this project. So I might be a little bit biased, but I think it's a super cool and very powerful CSS property that allows you to make it easy to help the browser only spend time rendering what's on the screen, not the size of the document. So please try it out and let me know what you think. Yeah, content visibility is definitely very cool. There's a web.dev post that I may not have written about it. So thank you so much, everyone. Thank you so much to our leadership panel here, Ben Govres, Ben Goodger, Prisa and Chris. This is definitely a very fun discussion with some of those spicy questions mixed in. And thank you, everyone, who submitted a question. We have a lot of great content for you throughout this week and the coming weeks in our virtual 2021 Chrome Dev Summit. So if your question didn't get answered, definitely sign up for some learning lounges, workshops and office hours for more one-on-one time. I'll be hosting office hours and learning lounges too. The schedule is live at developer.com.com. So thank you again, everyone, who joined me today and we'll see you online.