 They'll get everyone to quickly introduce themselves. Just say your name, say where you work, and say what one technology or possibility around all the things we've seen over the last few days that you're really excited by. But really quickly. So, Andres, go. You already know me. I work for Opera Software. I'm Andres Bolvins. And I'm really excited about some of the stuff I just showed you, ambient badging, and pop back into browser. Go ahead. I'm Jack Archibald. Hello? Yeah? I'll just shout. I'm Jack Archibald. I'm a developer advocate on the Chrome team. And I'm really excited about streams, as you heard yesterday. Hi, everyone. I'm Emily Schechter. I'm a product manager on Chrome Security at Google. And as most of you probably imagined from my talk yesterday, I love HTTPS and TLS and secure connections and all that good stuff. Hello, everyone. I'm Jungi Song, working on Samsung Internet team. I'm editing service workers. I'm Alex Pomeraski. I'm a product manager on the Chrome team. And I'm excited that the web still has that strength of no gatekeepers. That's really cool. Hi, Dan Applequist. Also working at Samsung and W3C Tag co-chair. So two hats on this panel. And I think I'm really interested in the experimentation going on, some of the stuff that Andrea has presented around what the lifecycle management of progressive web apps are, how they get installed, how we might be exposed to the URL, all that kind of stuff. Hi, I'm Alex Russell. I'm a software engineer on the Chrome team. And I'm most excited about how much faster you're going to make the web this year with all the stuff that we've just built. I'm Tall. I'm a product manager on the Chrome team. And I'm most excited about PageSpeed module and how you can use it to help users save data. Hi, I'm Ben Kelly from Mozilla on the DOM team. And currently, I'm probably personally most excited about Streams, because that's what I'm trying to implement at the moment. I think it's cool. Hi, everyone. I'm Ali Alibas from the Microsoft Edge team. And I'm really excited about Service Workers. I'm Tal Tran. I lead partnerships for Chrome and the web platform team. And I'm most excited to have everyone's phones be a combination of native and web apps. And it doesn't matter to the user. Nice. OK. So my name is Jeremy. I work at a little agency called Clear Left. I'm a web developer. And something we sometimes do when we're kicking off client projects is we'll have what's called a pre-mortem, where we say, OK, it's nine months out, the project's finished, and it was a complete disaster. What went wrong? And I'd actually like to do that in terms of the web and where we are. Yes, it's a very exciting time. But maybe it's good to get out into the open what the stakes are. And what are the worst-case scenarios if we fail with these progressive web apps here? I'm particularly interested in hearing from not just Google, but also from Microsoft and from Opera and from Zilla. So Ali, actually, how important is all this stuff? I think it's very important. Actually, if you guys aren't aware, Microsoft has this concept of a hosted web app, which is something that we had started back in 2011 as part of our web app's journey. And just recently, we have this thing called a hosted web app, which is basically just a manifest that you can publish to the store, which points to a URL. And then you can basically run your app inside of Windows, whether that's the phone or an actual desktop. And it runs it in its own contained state. So we do have some kind of history there with apps and the web together. And we're really excited with these new technologies, such as service workers and the cache and fetch and whatnot, to really bring forward some of the technology that will help us get to apps that are more like their native counterparts. OK, Ali, that wasn't what I asked. Ben, from Zilla, what's at stake here? How does the web look in five years' time if this stuff doesn't succeed? That's a good question. I don't have a crystal ball. I think all the data is suggesting more and more people are using mobile to start. And I think, as Alex has pointed out, a lot of people are spending the majority of their time in native apps. So creating a more compelling capability on the web for people to build useful sites that people want to spend time in is really important because there has to be a real value there for people to use the web on the mobile. And if we don't build that value for people and allow people to get locked into the silos again, I think we lose a lot of the value of the open web in terms of being able to share information freely, being able to not just consume the information, being able to share it freely, and have an open marketplace where new ideas can come in, not just in content, but also from browsers and whatnot. Well, in the case of Microsoft and Google and Apple, they got backups because they're not betting on the web. Andreas, Opera is pretty much all in on the web, right? It's all you do. So what does the end game look like here if these technologies don't take off? Yeah, it is a bit scary, of course, especially because we've invested so strongly in the web. So it's because we believe in it, and it's open nature, its power, and so on. So it has, I've been concerned or increasingly concerned about sites or services that just use a website to channel people to download the app. And so it's really exciting to see less of that and more an experience fully in the browser than handing off everything, all the exciting stuff, to native apps. So yeah, it wouldn't look so pretty, I think, if mobile was completely dominated by native app frameworks and formats. Daniel and Junkie, in your case, I mean, Samsung, you own the device. Why do you need to bet on the web? Because native works for you guys. Actually, well, web ecosystem is really important to Samsung as well because we have all the devices deployed out there, and we made our own browser. And also, it's a new ecosystem to us added to those Android and Tizen ecosystems. So we see our opportunities there together with you. So it's one of the reasons why I'm here to just say that it's not only Google, but we are here together as a team web. Yep, team web. I love that. Alex, everything's going to be fine, isn't it? I mean, five years out. If this stuff doesn't take off. I'd like to sort of flip the question. I know you're going to. I was going to flip the question later. We start with the dystopia, then we go to YouTube. OK, well, then I'll wait. OK, one of the stakes. My belief is that large stable platforms don't actually die. They just sort of pass quietly into the night. And so the web could do that. That could be a thing that happens. And more and more of the experiences that you want to spend your time in just aren't available there, especially as you switch form factors. Form factor switches tend to exacerbate those existing tensions. And so if we want to continue to have a free and open, interoperable, cross-device, cross-platform ecosystem that any new OS could show up and play in, or any new browser could show up and show a better way. I mean, what Andrea showed is incredible, right? The UI innovation that comes from not having a single gatekeeper like Alex said has made the web so powerful. And if the platform can't support the experiences people want to build, that momentum will slow. OK, so I want to address something. Because a lot of questions are coming in from that document and there were a lot of questions about Apple. When will mobile Safari do this? When will Apple do that? There's no point in me asking those questions to any of the people up here, because they don't work for Apple. I guess it is a big elephant in the room. They were invited, but they're not here. They generally don't tend to come to any events like this. But some people might think, well, you know, even if mobile Safari doesn't support service workers, that's OK, because I can install Chrome on iOS, and I can install Firefox on iOS, and I can install Opera on iOS. Would anybody from those companies like to explain exactly what those browsers on iOS are? Just clarify. Ben, Andreas? Sure. I believe the iOS store has a contractual constraint that they don't allow the execution of JavaScript for downloaded content that hasn't gone through their review, executed code that hasn't gone through their review. So you can't put up a generic browser that downloads JavaScript from the web and run it. And their explanation for this is to prevent malware. They don't want people to... There are other side effects, I guess you could say. So that means that Chrome, I believe, Opera and Firefox are all essentially wrappers around Safari's engine inside, and there's different ways of doing that, which I'm not an expert on, and we try to add value with the product layer and at the network interface layer, you can do some things by intercepting the network requests. But it's not the same gecko engine or a blank engine running there. So, OK, so there you have it. So you cannot install any other browser, basically other than Safari, onto iOS, right? WebUIFU, I believe, but there is a mode where you can switch to server side, press to rendering, but then, you know, the engine lives on the server, not really on the client. And even if you can, it won't support service workers either because that's sort of a different, you know, it needs to live on the client. So it's kind of a yes, but actually not really type of thing. So let's say on Android, where I genuinely do have a real Opera mobile installed and a real Firefox for Android installed, and if it's a Samsung device, then I've got Samsung browser installed as well as Chrome. All right, so maybe I'm trying different browsers. Let's say I visit a website that is a progressive web app in Opera and I add it to my home screen, or maybe I visit something in Firefox and add it to my home screen. Now, each time I open one of those things I've saved to my home screen, am I opening the browser again, or if my preferred browser is let's say Chrome, do they open in Chrome? How does this work? It's the first one. It's that you'll be opening it up in the browser that you used to add it to the home screen. And that's the same that if you've got like Chrome and Chrome Dev and Chrome beta installed and you add to the home screen using one of those, it will launch in the one you added to home screen using. Okay, is that because with progressive web apps the storage is done with the cache and each browser has its own individual cache? So from the user perspective it's actually, it could be quite confusing if you tap on a thing and you forgot that you added it with a different browser and then you clear out the cache and now you find the thing that you added to your home screen and maybe you even forgot was built using web technology no longer works. So that moment when you add to home screen we are increasingly seeing as sort of a special moment when you mint these things into something that feels more like an app. Okay, so it's the storage is basically at the browser level because it's individual caches. Is that the best idea? I mean we see push notifications happen at the OS level. Should storage be at the OS level? But let me ask you a question. How many people besides like us web technologists in this room like have like five or six different browsers on their phone that they use all the time, right? I mean most people have one browser that they use on their phone and it's because it's the browser that chip with the phone or it's the browser that the people that they know who knows something about this told them to use or they saw an advertisement for Chrome and they saw something. So then they're gonna stick with that. So actually I've been thinking about this issue too because you can have multiple progressive web apps from the same web app installed onto your phone simultaneously. Actually it's actually a good thing for testing. I'm not so sure if it's a real user experience problem because again I don't think most people use multiple browsers. Okay, well I'm diving deep in how I would interact with progressive web apps on different browsers. Let's say I go to example.com, it's a progressive web app and I install it to my home screen. Now later I'm surfing the web in a web browser and I follow a link to example.com. Now I take it that's just gonna open in the browser but could it perhaps pop open like an app? It's almost like web intense, right? Where instead of at the protocol level now it's at the URL level. Alex you look like you're thinking about this. Sure, yeah so we have a technical limitation today because of the way Android works. Other OSes could do a significantly better job here by the way, we've designed the technology between manifests and service workers to give you this idea of the scope for the service worker which joins up a bunch of different URLs. So we could say if you navigate to example.com slash thinger that is actually a navigation that should be handled by the example.com app. And we could send it there and we could open it in new UI. Today we have a system limitation on Android that prevents that. We can't know when a progressive web app has been uninstalled from your home screen and that means that we can't reliably decide to send you to a full screen thing because the home screen icon is basically the permission to run something full screen, that prompt that you're saying yes to. It's adding a capability to the website which is the ability to run full screen. And so if you've revoked that capability but we don't know it, it would be bad for us to just open it full screen again. But I think there's a future in which that's exactly what happens potentially where if you navigate to URLs that are handled by an app just exactly the same way they work in Android, you should be able to do that. You mentioned permissions there and it seems like a lot of what progressive web apps are doing is seeing what works on native and doing that. So nice having your icon on the home screen, launching full screen, all this kind of stuff. So I would say it looks more like native is looking at what the web does with permissions and copying us. Well, I was just going to say, should we be looking to native apps in the way they handle permissions? Well, no. So we've always gone with the model of ask just in time that we need the permission. And we're sticking with that. We're looking at other ways to innovate there. But it's very much things like Android are switching to a model of just in time thing. So we're ahead on this. Actually, what I've got here, speaking of native, looking at what the web is doing and kind of imitating that, what's the deal with the streaming apps, native apps thing on Android? Oh, Instant Apps. Yeah, Instant Apps. There we go. Yeah, so slap across the face to the web right there. So I don't see it as quite a slap across the face, I guess. And I think Google often tries to make sure that developers on different platforms can have be successful. And I think historically, when you look at web, you've had low friction, which is due to this incredibly powerful security model that we've honed over the past 25 years collectively, which is quite an accomplishment. It's low friction, but also low capabilities. And native apps have historically had high capabilities, but also high friction. And so progressive web apps has been a multi-year effort from multiple browser vendors working on service workers, push notifications to bring those high capabilities to the web. And I think that the Android native Instant Apps is kind of similar in that it's a multi-year effort to bring lower friction to native apps as well. But what I think is cool about progressive web apps is we've worked on this together. You've seen a bunch of different browser vendors who either have already shipped a bunch of these capabilities that you can use today with more on the way. And so that's what I think is really cool is you can go out as a developer and use this stuff today with progressive web apps. So Alex, how do you feel about streaming native apps? You want to succeed behind it? So I think it's great that lower friction allows users to be exposed to a diversity of experiences. And I think that's fine. That's really good. Not what I asked. So I think it's good that native apps are also learning from some of the things that web has done well. Just like I think it's great that the web has learned about some things that are robust, offline, push notifications, and other things that we learned kind of from native. I think that's great. I think it's interesting because last time we were on a panel together, it was in Brighton. And it was kind of at the time where some people were saying, should the web stop adding features for some amount of time? Should it stop developing? And the case I made then is like, no, we should look at the things that are successful on native, and we should take those. Because do you know what? They're coming for us, they're going to do the same. And this is part of that. They're coming for our best features. So we should go for theirs as well. This is the kind of dystopian five-year outlook I was looking for, Jake Grayson. But I wonder if the question isn't like what we think about whether we want it to be successful. I think at the end of the day, it's about developer success. And so making sure that developers have access, if you believe that your business is going to do much better on native, then I think we want you to be successful there. And if you think your business is going to do better on the web, we want you to be successful there as well. So I think for us, it's really about making sure that people, developers like yourselves, have the best tools across both platforms. Yeah. First day, we had great talks from you and Alex talking about comparing numbers between native and web. And there were some great numbers in there, like the average number of apps installed to a home screen and native apps is zero. Well, if that's the case, why are we chasing after the home screen? How will we know we've succeeded if people install an average of zero web apps to their home screen? Because then we've achieved parity with native. So for me, one thing that's important with this is with native apps today, there's this all-or-nothing choice. I haven't met this thing before. I don't know what it's going to do for me. I'm going to decide, do I want to add this to my home screen? Well, not anymore with streaming native apps, right? Well, I think that's the direction that's trying to get to something as well. But that's why I think with progressive web apps, it builds on that progressiveness. That's one of the reasons progressive is in the name is that as a user, you go to it. As you use it, as you build a relationship with it, you can progressively build a better experience with push notifications, home screen, and all the rest. And that you've spent time with this thing so you feel more comfortable giving it more permission to do extra things for you. It's not a cold call. It's not a cold call. You're not saying, hey, would you like my app? It's more like, you like this, do you want to keep it? And if you don't want to, if it's something that you're only going to, if it's an airline that you're only going to ever use once, or you don't think you're going to fly them again, you're probably not going to put them on your home screen. You're just going to use it from the browser. And that should be fine. And the whole application should work fine within the browser within a regular tab. Then you find out next year, actually, I'm going to be traveling a lot to Riga. I better put this on my home screen. OK, at that point, you can make that decision. It's like it's up to the user. And I think that that's an important aspect. The data usage is a huge thing that we hear over and over and over again, even from users in wealthy Western countries. Yeah, the storage constraints that devices have, ignoring even the data costs or the fact that you need connectivity to install it in the first place, just create a huge difference in the accessibility of even trying something out for the first time. And so I think we do need to both go in each direction, but each has something that it's geared towards. So if you're building an experience that is really targeting users who are just coming online, a native app might not be the right choice. And a web app is probably the right choice to remove some of those barriers. But there are other situations where it might be the reverse. And the user shouldn't have to pay the price. Us as developers should pick what's best, and probably try to sell it. Tell me about the next billion. What kind of devices are the newer things, older devices? What are the data technologies? There are new devices in that they're being built, new, and they're released in certain years. But a lot of their specs are ones that we associate from previous years in some of the more developed markets. So in the US or in the UK or Europe, they'll be devices that we think of from several years ago. They may be shipping jelly bean on the device. Size might be a lot smaller. Amount of storage space and RAM will be a lot smaller. People rely a lot more on SD cards, which means they can also remove it and hand it to someone else. And so how people are actually interacting with data and storage constraints just varies pretty drastically. Yeah, so I guess, I mean, the responsibility is on us to be responsible with storage. And I think it's something, Alex, in your talk yesterday, you were showing the AMP demo there with the Washington Post. And you click through and there's the Washington Post AMP and it was able to install the service worker with that custom element. But I was looking at the URL bar and that wasn't the Washington Post. It was on the CDN from RAM. So I talked to Paul back to explain it's an iFrame and using an iFrame, you can install a service worker from someone else. Emily, that seems to violate the principle of least surprise to me, right? I thought the whole idea with service workers was it can only, you know, same origin. And I realized iFrames kind of are just a browser window but I mean, we could abuse this pretty badly, right? And fill up a device with 20 service workers when you've only visited one web page with 20 iFrames. So service workers require HTTPS and I explained some of the reasoning behind this yesterday. It's absolutely like one of the reasons is because service workers sit between the browser and the network, right? And so that means that any person on the network could be managing the requests that were sent back and forth. And that's actually why we require HTTPS. But is the iFrame thing a bit of a loop hole there about the same origin? And that, I feel like I'm visiting one URL and yet it's installing service worker or service workers for another URL. So one of the things about this is actually if you embed an iFrame today in another page and it might store stuff in index DB, you can do the same, you can have the same kind of behavior. And so actually one thing to clarify is that service workers using the same storage that the website would have been using, using other technologies, index DB, the cache, others. And the browser reserves the right to evict those under certain conditions. And so it's similar actually in practice to what's been possible to date. That specific demo, the AMP install service worker element on the CDN hosted version of that document, that element is a little canny. It looks to see if the canonical URL in that document is the target URL that you're trying to install for. So it won't let you install them willy-nilly. It has to be the same document there. So that's built into AMP install service worker. But I could, I mean I could put on my website a bunch of iFrames that load other websites Absolutely and this is actually part of the web's most powerful, second most powerful feature. The first one is URLs of course, but we do runtime composition like no other platform ever has or ever can in a safe and trustworthy way. Like we are only because of the safety that Alex mentioned earlier, because we've actually honed the security model where we are relatively good compared to other platforms about user privacy and security. That's the only reason we can do anything across origins with mashups. So I mean, yes, but that's the status quo and it's also an incredible power that we've got and nobody else can get. So that storage demo that we saw earlier, storage abuser thing, that is using iFrames, it's not using service worker, it's just iFrames and index DB and everything. So it's not a new problem. That's iFrames. I just wanted to point out also that there's room for browsers to add some features here like you can go and turn off cookies in third party iFrames, it's very similar to that. And currently in Firefox, if you turn off third party cookies in iFrames, we don't allow service workers in those iFrames either or index DB or any other storage. And so I might be wrong, but I think Safari has that turned on by default. It'll be interesting if and when they implement if they make a similar decision. Speaking of the things that browsers can do differently, we're all familiar with the Chrome algorithm, I guess for adding to home screen, right? It's gotta have HTTPS, gotta have a service worker, you gotta interact with it a couple of times. Andres, is it pretty much the same for Opera or tweaking it? Install banner, you mean? Yeah. For now, it's the same. It's the same? We've implemented the same logic simply for consistency, but we could tweak it. It's like there's other, you know, could be other conditions, but it seemed pretty reasonable. And then currently Firefox doesn't have any automatic. We're still looking into it. Like the experiment that was run was very, you know, if you visit it five times in a period of time, we would show it. But I think we need to have a designer look at what's right there. I am a little bit cautious just because this is a heuristic that's not specced. Almost, I think it's on purpose to allow some innovation here. And at the same time, we do see some convergence on a single heuristic so far. And the feedback I've gotten from developers is they care a lot about it. So they're trying to meet that heuristic. And so concerns me a little bit. That is not specced. Ali, is Microsoft gonna have an automatic banner pop up? Yeah, we're looking at a few options. We're still in our planning phase for this specifically. But we wanna be as, we wanna not be as restrictive as we can. So for example, if you have a responsive application, you have a web manifest. We think that's enough for you to declare that you're an application. We've also talked a little bit about in that post that Jacob Rossi had about the progress of web apps, how we're looking at maybe leveraging Bing to crawl the web, to find any manifests that we wanna ingest as apps into the store. So that experience would actually allow you to install with the store onto your machine. And the other thing the browsers can do differently is like, Andreas, what you said is stay with the ambient badging. It's like shots fired, operators taking the lead here. Beat that, other browser vendors. Any plans, any ideas? You wanna share this with the rest of the class? Well, first of all, I wanted to answer your previous question about the heuristic because actually Samsung browser have more like what Ali was talking about, is just purely needing the manifest file. So you're saying HTTPS is not a requirement? HTTPS is a requirement. Oh, okay. Just wanna verify that. No? It's actually, it's not a requirement because it doesn't really require service workers yet. But there's a history. Like we shipped W3C manifest in our 3.0 and we shipped service workers in 4.0. So by that time we shipped W3C manifest, we just wanted to deploy it and we found that some of the content providers in Korea actually use it as a hosted web app. And that's why we actually started from there. So we are still experimenting that what would be the actual, actually better user experience, also distributing this progressive web apps in a better way. So we are still just working on it. Emily, I take that the progressive web app at the home screen is a nice carrot for you to dangle in front of people and say this is a reason for moving HTTPS. Sure, you could say that. I think there's a lot of different reasons why we want people to move to HTTPS. Do you tend to prefer character sticks? Do you like to threaten people that they should move to HTTPS or entice them to move to HTTPS? I think both could be useful in certain situations. But I think we like to think of HTTPS as actually one of the things that enables the web to be so open and so low friction. And so it's actually a very positive thing. Okay. So on the ambient badging, if anybody's got any other ideas, just shout them out. I just want to say I think it's awesome to see what Opera is doing here and I think it's going to be really interesting to see what other browsers do because it's not 100% clear what this should look like and that's one of the awesome things about having multiple independent implementations that are looking, trying out different UIs and seeing what works best in practice. So I think another thing I want to emphasize is that we've heard a lot of developer feedback from a lot of folks and that's led to us changing some of our heuristics right now. And one thing that we've seen again and again is there are some use cases where the very first visit you know as a user, I want to add this to my home screen and you want some way, some affordance to do that or know that it's a special thing. And so we've also exploring some ways to do some ambient badging for progressive web apps as well. Something else that comes up in the idea of discovery or re-engageability with progressive web apps is the idea of oh, we need a progressive web app store or now we see Microsoft are actually going to treat them like regular apps, right? We'll be first-class citizens in terms of other apps. They'll be right up there with other native applications in the store. So when you search for the app, you'll find it like any other application. But do we need a progressive web app store? I mean, it'll be the same thing. But isn't Bing.com a progressive web app store? Kinda. I think about this in terms of distribution. You make an experience and you want to get it in front of users and what's the way that you can do that most effectively. As a developer, you're trying to get users into your experience and as a platform, we're trying to make sure that only experiences that are worth keeping are things that you're actually sort of in your face to ask to be kept. So that's where the heuristics come from. But discovery can happen in lots of different ways. Search is a great one. I'm so excited that Microsoft is doing the store route. We've talked a lot about that on the Chrome team. I think the ambient badging that Opera is leading on is outstanding and I think we're gonna see all of the above really because we're here to try to help you get your experiences in front of users when they like them the most. But I do think that I would like to see as tightening, as in your personal opinion, tightening the heuristics from what we have now in Chrome. Because we detect a service worker now, but I want us to get to a point where we're detecting an offline experience. I mean, at the very least, the fallback page. I really want us to be able to build user trust in the things that end up on the home page. And I think if we end up showing browser error messages, that's, there's no trust there. And so interesting, in your Prompto ad home screen, you also don't accept display browser for adding that prompt. Is that for me or? Yeah. I think we do actually. Oh, so there is a difference. In the, yeah, we do accept display browser as well, as far as I know, at least, I'll have to check, but yes, yes, we do because in the Guardian it works. Opera takes the lead again. All right. But I think it's, I think this, you know, having these strict heuristics or like strict rules for when it's shown, both in terms of technical capabilities and user engagement, they're pretty crucial. At first, you would think, well, let's try to make this as easy as possible for developers and just show it as soon as possible and so on. But then aside of this maybe not being ideal for the user, it sort of also, I think, makes everybody a bit lazy. Like, well, it will work and I don't have to do much. Just include one file and it's like this magic file you put in the root and suddenly everything, you know, you get all these banners for free and possibilities to get used to adding to the home screen. I think it's good to start with pretty strict requirements and maybe even make them more strong over time just to sort of make the web better and make it really worth it. Like, because adding something to the home screen is like a special thing, right? It's like a privilege. You know, it's a privilege, right? It's like a certain KPI, if you will, like kind of a conversion event or whatever you call it. And I think that's important to keep in mind. Apart from Samsung, all of you that make browsers, so you also make browsers for the desktop as well as mobile, how does add to home screen look, work feel on desktop? I mean, I use Slack and it's a desktop app but I know under the hood it's actually web technology. So any ideas on how we're gonna cross that uncanny valley? So you've heard my answer. You guys have seen probably the WhatsApp for desktop, which is basically just a web view instead of an application that you could put on your desktop. So as far as you're concerned, it's an app and that's sort of the same idea with Windows. But the install process there is you go to the store? So for that, the WhatsApp example is you go to the site and you install it from there but for what I've described earlier, you'd actually go to the Windows store and you'd search for the application and then you can install it. Okay, I'm in a browser, I'm at a URL, it's a progressive web app, I'm on a desktop browser. I want this installed. So we've actually launched an add to shelf, but a butter bar inside of Chrome for Chrome OS. So that exists today, so if you load a progressive web app there, you should get it with the same heuristics. We're still looking hard at what that would mean or what the UI would mean. Desktop is, we supported a bunch of desktop OSes and there are a lot of differences in getting high quality system integration. Actually it's a little bit easier when you just have one activity at a time in Android than it is to sort of like handle all the tab and all the rest of the details of the desktop OS. I'm again, extremely excited that Microsoft is gonna lead on this. Yeah, great. Just to check, because I'm running out of time, do people in the audience have questions? Eager, we have a couple. Okay, well let's get Paul to throw the microphone. Where's Paul gone? Hey, he's got the microphone somewhere. You can throw it over there. Meanwhile, I just wanna be setting up while you're getting the microphone. Yesterday, we're hearing from Matt a lot of disdain for documents and a lot of excitement for apps. And we've been talking about progressive web apps. I wondered if anybody here could tell me what an app is. Anyone. As opposed to, you know, the rest of the web. Progressive web app is a marketing term. No, but just app, just app. What's an app? Can I try it? Yeah, go. I'm gonna be the fool who tries. Don't do it, don't, it's a trick. It's a trap. It's not an app on Android because it's made with Java. It's not an app on Android because it's made with C++. It's not an app on Android because you distributed one way or the other. Side load in APK. It's an app because the overall user experience is set by the OS about what is a first class citizen and what isn't. And so being an app is simply meeting the user's expectations of all of the other things that the OS has given privilege to and all the other affordances that you're integrated into. And that's what an app is. Is that what you're seeing, Kyle, when you, you know, looking at native, looking at web, do people generally think, like, it doesn't matter. It's just an app. I will come from a non-technical perspective on this. I mean, when I think about an app, it's just people just think of better user experience on mobile. I mean, that's, you know, so we often describe progressive web apps as like these app-like experiences. So people think about it. It's just a more like native access to probably the OS, access to the device, being able to actually feel like a rich, fuller experience. So I think about it in terms of what the user is able to experience and less so about kind of the distinctions in terms of technical specs and stuff. So is it an app when it's still in the browser? I have not had my home screen yet. Is this an app? Anything that is an application that you interact with to achieve some goal is an app? Is my blog an app? Yeah, yeah. Google Maps on my browser is on my computer. Yes, well, yeah, I think so. You know, yeah. You know what this thing's moving. It's a truck. I know it's a truck. That's amazing. We can divide the whole web into apps and documents. Isn't that something? Yes. Up to your mouth, please. Don't lick it, but close to the mouth. When you are browsing in the app store, you see how big an app is. And when you try and install it, you don't have enough space. Well, it's as sorry you can install it. And then you have to choose what you remove. But when a progressive web app, you install it, and you don't have enough room, the browser decides what to remove. And then the user loses, might loses an app that he likes to keep. How do you think about that? So this is part of the storage API that we saw earlier, this idea of being able to request persistent storage. And if you're granted that permission, then you can store as much as you want, and the browser will not remove it. And the hope is we can get to a position where if the device does come under storage pressure, then you'll go to the menu you go to where everything's listed with the biggest thing at the top. But it won't just be Chrome sitting there using gigabytes. It will be origins. All of your persistent origins will be there separately, so you can decide, do you know what? That game can go, but all of my offline videos can stay. You can cache the request with the service worker. Can you upgrade that to a persistent storage? So I just want to just clarify. We've pulled the world's largest bait and switch at application installation time. By the time you get that prompt at the bottom in Chrome today, we've already done all the work of storing everything. That's the best part, right? You're already using the thing. The question isn't, do you want to install it? It's, do you want to keep the thing you've already got? We're doing upsell. We're not trying to get you into the car in the first place. It's like, do you want leather seats? There was somebody else had a question right behind you, saying, OK, just throw the microphone back there. It won't hurt. And I think it might have to be the last question, because I don't know about that. Hello. I have a question. It's too loud. I have a question related to the future of native apps. So some years back, everybody wanted to have an app, because it was the app boom, so everybody invested money. Developers invested time learning, new stuff. And now we see with progressive apps that we are moving towards a different paradigm. So in the future, if these things really, like, it's a thing, what will be the future of native apps? Why would I want to install a native app if I get the same from this? This is brilliant, because this is pretty much ties into how I was going to wrap this up, which was instead of the pre-mortem, we'd have the five years out. We've succeeded. Progressive web apps, people are using them. But this is a great addendum to that. What are people using native apps for in this beautiful utopia of progressive web apps? Who wants to talk about this future? I'd say that how high games that require high CPU and high GPU will be the last things to come to the web. The last bastion. OK, games. Yeah? Well, in 2006, I posted a vision of a future of web. I'm a future of mobile, basically. And because I saw that a lot of people were starting to, this is pre-iPhone, a lot of people were starting to download internet-connected apps for photo sharing and all this kind of stuff. And my view, which I still hold, is that native apps are going to play a role in that. But more and more, the web, and alongside of the web, sorry, the web and native apps should both play a role. And we want the web to, wherever possible, become the vector for whatever experience the user gets, for whatever applications the user is using, so whether that's a native app or a web app. So I think that's the future that I see, because I think that we're never going to do away with native apps, and nor should we really seek to do that. But I think that if we make the web as good a platform as it can be, then we're going to make everybody's lives easier, including users and developers. And Ali, you have a vision? I think we shouldn't think of this as a competition. I think it's more about providing options for developers. So whether you're a web developer or your C++ developer, you have options. OK, Tal, paint me a picture. Five years out for the next billion. How does life look? Well, I think there's always going to be a next billion, at least given our population growth around the world at this point. So there will probably be a new next billion. Hopefully the billion we're currently thinking about will be online. And ideally, if we do everything we've talked about here, able to access really great experiences even under the conditions they're in. But I do think we'll see probably devices that we think are top of the line today that might not be considered top of the line in three, five years. And while we're seeing really a lot of improvement in network connectivity around the world, and I know there's a lot of ambitious goals in making that the case globally, there will still be people who are coming online for the first time and don't necessarily have the context that we all have with the internet and have their different contexts. Who knows what form factor it will realistically be. Maybe it's going to be some crazy thing you wear on your toe. Who knows. But there'll be people who have never interacted with anything. So as soon as we're looking at these transitions, there's always going to be an next billion. I don't think it'll be solved. And we're going to be needing to adapt. And I think the biggest takeaway is just think about people who come from a context different than your own, and figure out what that context means for how you can make sure that the problem you're solving can be solved for them as well. Brilliant. OK. I'm going to wrap it up. I want to thank all the panelists. I want to thank Paul Kinnell actually for asking me to moderate this, because I thought that was pretty brave of him. But ladies and gentlemen, we're having a lunch break next. But please give it up for all these panelists. Thank you.