 Yeah, so you've been submitting your tough questions to these folks, and I get to hide behind those kind of spiky words and demand some clean answers. So yeah, let's get straight to it. So this first question, which has been submitted anonymously, which is always a good start. At the home screen, it's pretty good, but it's not in the app launcher. It doesn't show up in battery usage or data usage stats as a separate item. Can we get that? Grace, do you want to start us off with that? It should be on already. Is this working? Yeah. Yeah. So we're definitely aware of this, and we're working hard to try to make the at home screen behave more like a native app. And there are some complications, like I think I mentioned for the battery usage, that we can try to do a better job, but for data usage, is at home screen still run inside a browser process, so and then in Android platform, that's just a single process. So we have some challenge to work on. But the ultimate goal is to make these... Yeah, definitely a more like, I mean, in the coming year, what do we try to do is make it a more like a native app from the user perspective. Yeah. So this next question is also anonymous. Is ServiceWorker ready? I'm going to, yeah, what does the audience think? I don't know. Do you think it's ready? Yeah. Okay. Well, moving on. We've had 2.2 billion page loads a day through ServiceWorker, and 350 million push messages a day as well, and 2,300 sites using push. And yeah, okay, it's at the moment, Chrome only, well, we have Opera support as well, and Firefox support. They're hoping to land that early next year. So it's on their standards track now. So yeah, I'd say it's pretty ready, but the important thing here is it's progressive enhancement. Like, you know, pages aren't going to break in browsers that don't have ServiceWorker. And I think, I really think that developers are in a position of power here, that if you want to, if you start using ServiceWorker and you can make, you know, your sites have more features and run quicker with ServiceWorker than without it, then for other browsers, that's going to show them, look, you know, if they want to compete on the web, they need to have ServiceWorker as well. I reckon. That's what I think. If you want to ask questions during this event. We also have a microphone in the middle there. So if you want to ask a question live, then please do come down at the aisle. It's sort of a weird kind of wedding venue. This isn't it, especially with all the white chairs, but if you want to ask a question, you can. I'll go on then. Because since you've got up, it's sometimes difficult to find someone who's brave enough to get to the microphone, and that person is you. What is your question? Hi, I'm Paul. First of all... Would you like a job in DevRail? The platform, thank you, yes. Really great conference, it's really nice to be here. I have a question because I heard a lot of web APIs and how the web works, but I haven't heard nothing about the Chrome apps and Chrome extensions, and this API, is it something that's going to happen over there, is it going to be available, and so on? We had one question as well. It actually ties in very nicely to the next question we're going to ask, so we can sort of roll that into one, which is when is Chrome OS and Android going to merge, and how soon can we develop apps for that? So Darren, do you want to take that one, and the question is that? I can talk about all of these things, but first off, to your question, Chrome extensions, Chrome apps, these are parts of the platform, these are parts of Chrome, they are things when it comes to Chrome extensions, we're invested in enabling customization of the browser, you're going to see us continue to evolve that. What we were here today and yesterday to talk about was really the things we're doing to enhance the web platform as a big focus of Chrome, and focus on the web itself, the web ecosystem. Historically, at this summit, we've talked about the whole spectrum of things that Chrome is doing, but we really wanted to focus in on progressive web apps, the mobile web, and all the things that you guys can do to create great experiences there. When it comes to Chrome OS and Android, there were certainly some interesting press recently. I just want to re-emphasize that this idea of Chrome OS being folded into Android, it doesn't make a lot of sense, in fact Chrome OS is an extremely successful operating system. If you think about in particular where it's been so successful, because of the simplicity of the system, because of the web really, it's been a fabulous computing platform for education, businesses, and many homes. It's really something we started six years ago with this idea of bringing the simplicity of computing, speed and simplicity, security, and these core values, the things that make computing just less painful, to try to create a simpler computing experience that people really love. I think we've been pretty successful here in Chrome OS as something that we're really behind in trying to grow, and in particular, now that you can totally imagine that as the teams work together, they're going to look for opportunities to leverage across Android and Chrome OS, especially under the hood and so on, but as far as how that evolves, I think the number one thing to keep in mind is that that vision, the core user experience of Chrome OS is a thing that's here to stay and we're fully behind. So, if you look at all the things we're working on, on ChromeSatis.com, on the open web platform, you'll see a lot of the APIs, sorry, a lot of the functionality from the Chrome OS APIs that we're working into the open web, right? It was just in the office earlier this week, and I saw one of the Chrome apps engineers with Web USB running, blinking lights and everything else. Now, there are some security things that we need to get past on that one, but we're very focused on bringing all of this functionality to the open web. So Chrome works great on new devices like the under Nexus range and things, but in some parts of the world, brand new devices have small screens, half a gig of RAM and limited storage. How important is it to Chrome to ensure that Chrome works well on these resource limited devices? And what are we doing in this area? Grace, do you want to take that one? Sure. I will take it again. So, we call the low-end devices very important for us, right? So this year, we spend a lot of time trying to, especially working on the memory footprint, and we achieve the 30% memory footprint reduction for our browser process. And for, thank you. For the render process, we're working on the, so that 30% is especially for the low-end devices. We're really targeting the market to try to make sure 512 devices works well. And for render process, we're actually having a cross-the-board effort, as I think yesterday mentioned, for the VA to reduce the memory usage, there's like a 10% in the render process that will be benefitted low-end devices too. And we'll continue looking into what else we can reduce in the coming years. Well, one of the questions I had via email recently is, a lot of the devices in, they don't have a lot of on-device storage, and a lot of the storage is deferred to SD cards. Are we looking at anything to be able to move Chrome storage, or even for particular origins, move the storage onto the SD card? So we are looking into that. Because SD card, every app, if they have the permission to access the external storage, they can access. So we have to ensure user-aware, the particular local storage data for the origin can be accessed by the other app. And then we need to build some permission model before we can move the data storage to the SD card. So this next question is for Parisa, I think. And it's quite a pointy question, but are you hiding over there? So I'll read it directly to you, because I think that's how it's supposed to be written. The deprecation of APIs and features on HTTP is causing developers pain. Why are you forcing this upon developers? What are you doing to help make HTTPS easier for developers, especially on intranets? Yeah, well, obviously whenever there's an opportunity for pain, I take it. No, so HTTPS is really important. Did anyone see Emily's talk yesterday? Awesome, if you didn't, yeah, it is deserving of applause. So she went over, I think, the motivation for this better than I'll be able to. But HTTPS is really important. Without it, as a user and as a developer site owner, you can have no expectation for security, right? So for really powerful APIs, one of the APIs we deprecated recently was GetUserMedia. So having access to a camera, a device camera, we consider very powerful. And something that really should only be done in a secure context. So that user can have some expectation that the bits they're sending to a site have not been tampered by some third party. And the developer also can have some expectation that no bits that you're sending to the user have been tampered or snooped. So we think HTTPS is really important. We're doing a lot of things to try to ease the path. Emily's talk went over things on the web platform in terms of features that we're supporting, as well as a new panel that we just added to DevTools to try to help developers who want to support HTTPS to get to green. But really, we think it's the responsibility of us to make sure that really powerful features are only accessed in a secure context. So we've had a question in from Slack. Yeah, you can ask questions on Slack as well, and they get forwarded into this Google Doc I'm looking at. This question comes from Oliver J. Ash, who's from The Guardian, the developer who did the fallback offline crossword page, which I think is brilliant. We've seen a lot of stuff around service worker, these new features, push messages, but we're not seeing many Google products using these things. When are we going to start seeing Google products, such as Gmail, inbox, Google+, when are they going to start using this stuff? I'll direct that one at Alex, I reckon. So I can't speak on behalf of any of the other Google products, I guess. But just like a lot of you are experimenting with these technologies and seeing how they can make your things load much quicker, be much more robust to flaking networks, I think that these are things that would also make a lot of sense for a number of the Google web properties as well. So although I can't announce anything, I think that would make sense. So we're kind of seeing on the web a resurgence of SVG, because SVG's been around for ages, and kind of when it started, spec people or browser developers were going to web developers saying, hey, do you like Flash? We're like, not really. Do you like XML? No way. Well, you're going to love SVG because it's basically both of those things. But we're looking at deprecating Smile, which is the animation system. So we had a question in about that. Are we going to break all existing Smile content out there on the web by removing this from the platform? Dmitri, do you want to take that one? Thank you for not making that question too pointy. Why or why or why are you breaking the web? That's more appropriate. And the context here is that we did recently, well, not recently, but this spring, started talking about removing Smile SVG feature that enables your animation. One of the weird things there is that the reason why we're doing this is because we actually don't see the path to interoperability, which is this working in every browser. And so at this point, it's just two browser feature and no other browsers want to do this. And so we are sort of like in this really hard situation where we're like, do we carry this along or do we remove it and make our burden a little less? And obviously, this involves developer pain and we felt it very hard very much on the Blink Dev, which is the mailing list where all these things are announced. It's now a center thread with people chiming in very regularly. Yes. And the interesting thing there is I want to say that, first of all, some of the things that Smile does today are simply not easily possible with the Web Platform features. I think I want us to first get to the point where we can say with full honesty that we can complement the features of Smile with the corresponding Web Platform features that are on an interoperable path and then maybe talk about deprecation or removing at this point. At this point, this Smile thing thread is mostly a heads up. We know this is not going anywhere. So take a look. I guess part of the plan as well is for the animation API in JavaScript to start taking on a lot of this stuff. Web Animations is actually one of the interesting parts of that and I'm going to do the it's happening thing. So it's actually being implemented across the board. That's really cool. Very excited about that. But there are still some pieces missing. I mean, we're seeing SVG was unloved for so long. But with devices of different density, especially people are starting to pick it up again. But I mean, the implementation we have still inherits a lot from WebKit, the initial implementation, and same for Safari's Firefox implementation is all as well. It kind of feels like it's only Internet Explorer and therefore Edge that have kind of shown the way with you can make SVG perform really well. Are we going to step up our game there? Is that something? Totally. We're totally stepping up our game. And we want to make SVG as performant as it can possibly be. I have to say that as a platform developer, I'm amazed that people can use this thing because it's one of the most terrible spec APIs ever. And there are some places where you don't want to go in there because bad things will happen to you type of alley situation. And still, like yet, it is a success. And it's kind of the story of the web. The thing that wins is not necessarily the best-designed one. And so, yeah, we want to work on this. But we also kind of want to look forward ahead to SVG2 and prod the SVG working group along a little bit and say, hey, come on. Come on, it's been two years. Give us something. And so get something going there. So we've got another standards-based question. I'll just read it out as it's been sent in. Pointer events. Seriously, when is it happening? You've been promising it for ages now. Grace, do you have that one? If you check the checking log, it is happening right now as we speak, right? So it is behind the flag. And then I think I see Rick over there. So he's leading the Eifer. And then there's a CR bug. I do not recall exactly a bug number. If you want to know, you can find Rick after this. And you can, yeah, I see him waving his hand. So you can follow the bug. And he also has a Twitter feed updating the status. So you can follow him on the Twitter. And today, I believe it's soon. I think soon, behind the flag, you can try it out. And there are some technical hard things we need to figure it out so we don't have exactly date. We're going to turn it on by default. Hope sometime soon when Rick figured it out next year. And please be nice to him. He's a really cool fellow. So just take it easy. By the way, I love the way you ask the questions and read them out. Just you have to do this everywhere. Well, we've had a question in from Twitter that's been pasted into this document. And I'd like to thank Paul Kinlan, who's managing this at the moment, especially thank you for posting every question and using a different font. That's not messing with my OCD at all. This question comes in from Henry Helvetica. Could be real name? I don't know. So the way Chrome pushes forward, how did the panel feel about PPK's call to slow down? And I'm specifically not allowed to answer this question. I think that's because I've already written blog posts about it. So just a bit of background, PPK wrote this blog post saying, the web platform is progressing too fast. And we should stop doing it for like a year, for some reason. I'm sitting on the fence about this one. But are we moving too fast on the web? Are we making other mistakes we're making by trying to push the web forward so fast? Or should we be moving even faster? Who wants to take that on? Yeah, so the way that I would measure this is what is the developer adoption of the new things that we're doing. If there's a big gap there, then maybe we're moving too fast. But there are certain things like we got service worker out there really fast, which was really fast. But this one really fit our model of how we want to move forward, which is an extensible platform and explaining the platform. So I don't want to just throw in tons of APIs that no one will use. So always looking for that feedback. That's what we have on Chrome status, all of the histograms and what people are using. I think too, for things like service worker and a bunch of these other things, we worked very closely with other browser vendors and standards committees and standards bodies. For example, with service worker, we worked incredibly closely and co-developed that with Mozilla and other members of the standards community. And if other browser vendors are coming to the table and having meaningful discussion, other people are implementing, developers are using. I think to me that says, no, we aren't moving too fast. No, we're actually moving at a pretty good pace. And don't forget that if you want to ask a question live here, the microphone is just there. Someone's already done it, so it's not as scary anymore, right? So if anyone's feeling brave, you can come to the front. So I think we can answer. Oh, sorry. Go on, go on. Gary's right now. Sing a song. Don't let me stop you. No, I was just going to say that this whole past year, we've had a real focus on just the core engine and just optimizing existing code paths and prioritizing scheduling work much better, all to bring a lot of wins to the platform. A lot of the V8 improvements came from just being smarter about scheduling. And with the focus on emerging markets, there's been such a focus, such an emphasis placed on being smarter about resource loading and scheduling all this stuff. You have pages with lots of iFrames, cross-origin iFrames, making sure that the main document content is given the right priority, et cetera. There's just so much we can do when we really focus on the core engine. So I think part of the answer to that question is it's not always just about new APIs. Sometimes there's real holes that need to be filled, and that's where something like ServiceWorker comes in, push notifications, et cetera. But a big part of this is just making sure the engine works well. And that you, as developers, have a lot of control. The engine shouldn't feel like a big, mysterious black box, right? You should feel like you have a lot of control dev tools to help you understand it, et cetera. So there's just a lot of work going into the core platform. And I think that stuff really pays off. I want to refund that a little. And actually, PPK's post, I had a little milder response to it than maybe Jake. And basically, my question, my thing was that if I were to summarize it, I would say, the question he's asking is, to what end? Why are you doing this? And I think this is what Greg said, is that you have to be good in order to deliver things that are valuable. You have to get really good to develop, to listen to developers, at listening to developers, understanding what they want, and building something that the question is, are you moving too fast? Is like, has such an obvious answer, right? Because it's like, yes, because the developers need it. And it's really obvious to me that this is necessary. And that's the next step. And I think that's what we've been doing. And I think they're underlying the quality and excellence of the product focus that we're trying to do in balancing that. I'm really optimistic about 2016. We are not moving too fast. We are more focused and better than ever. Yay, web. Well, I had an angrier response to it, like you say. But I tried to channel that anger. So if anyone's interested in hearing that on the latest episode of the HTTP 2.0 Free Podcast, I wrote a five-minute poem about how disgusted I was about this idea that we should stop on the web. That's the thing you might want to check out. Yeah, exactly. May as well. I've got a room full of people in the live stream. I'm going to plug my podcast. You know, do you want to ask a question? Yeah, hi. I'm not Paul. So when there's so many visions and directions for the future of the platform, how do you unify and prioritize all these ideas? So that's a good question. Let me take a stab at it. I think it's very important for us as a team to pick the battles we want to fight, to pick the problems we want to solve. And so for example, for this year, you've heard some of the themes in this conference. Performance is a big issue on the mobile web. We want to really invest and make appreciable progress on it. Emerging markets and serving the next billion users who come online is a big focus. And so really what we look at is we sort of look at what's happening out there, look at what users are doing, look at future trends, and then make a very deliberate choice about where to focus our efforts, and then align behind that. And then there's definitely a lot of ideas that come up midstream, and you try and incorporate those in. But the idea is not to be spread too thin. So you don't want to make 10% progress on a variety of fronts. You want to just nail a few things really well. I would emphasize too that this web platform, it's an ecosystem. It's a community. That's why all the work we do on Blink is fully in the open. That's why Blink Dev encourages folks to come in and share their perspectives and their feedback on proposals. People float there. We had a Blink on contributor conference last week. We had a whole bunch of folks there from other browser vendors as well. And so it's ultimately by talking to developers. It's by observing places where there's obvious gaps that we're hearing again and again from folks they need. But it's ultimately a collaborative process, because we're kind of all in this together in a way. I just add one extra thing to that, because I think it's challenging having to prioritize all these different things you want to do. And one thing that's really helpful as Chrome has these guiding principles of simplicity and security. And any time we find ourselves maybe excited about one idea and getting away from those core principles, it's very helpful to refocus and sometimes prioritize. So moving on to Polymer. Does Polymer support progressive web apps? There seems to be a big emphasis on server side templating and rendering when it comes to this stuff. Is that something that Polymer supports? Yes, so it does. I mean, if you watched Rob's talk yesterday about that, it was building a progressive app in Polymer. So you should probably pay attention next time. Good quick answer, fair enough. No, actually, I can elaborate a little bit more on that. So I think if you look at Paul Lewis's recent blog post about performance on frameworks and how they impact things like RAIL, Polymer came out really well in that comparison. It's relatively small. It's relatively fast. I think there's some things we can do to make that faster and get first paint quicker. And we're working on that right now. But we're already in pretty good shape. And I think when you start to see things like server side rendering, a lot of the reason for that is because in certain circumstances, other frameworks have much bigger payloads and much more JavaScript that they're passing down. And you have to do something different on first paint as opposed to later paints. And our goal is for Polymer to be really, really fast, have a really fast first paint, and still with idiomatic usage without having to resort to tricks like that. We've got the paper elements that doing a lot of the UI work. Are they going to support async? Because that seems to be one of the things that you really need to get this kind of first render down. Yep. Absolutely. That's some of the stuff we're working on right now. So we've got a question from Slack from Simeon. So one of the big warts of the current progressive web app story is that we don't have a good way of handling mixed contents or cause. And I think what we mean by handling here is a native app can download podcasts, RSS feeds from anywhere on the web. It doesn't have to be cause compatible. And if you're wanting to build something like a podcast app, you can't really do that on the web at the moment without building your own proxy to send everything through, to not lose the padlock or to get ad cause headers on. And in the case of a podcast app, some of the files are going to be huge in doing that. Do we have anything, any ideas on how to address this gap? Prisa, if this is mixed contents, do you want to take a stab at this one? I don't have any great ideas, but it's a real problem. And something we should think about more. I don't have any great ideas for it. I think it's a legitimate situation. One of the requests we get quite a lot is to say, why can't we just make a request to anywhere on the web and get the content? Because if we don't put cookies on it, then it's not leaking any data. But the situation we have there is we don't want the web to be able to access things like your local servers. I mean, if an evil page could just do a port scan on local host and look for sites that are there, I mean, that's basically where you'll be running prototype servers, new stuff, stuff that you don't want leaked onto the web. And same goes for intranets as well. So I guess with that question, I don't have any good ideas. Anyone have a good idea? I have a larger thought about the importance of the security for the web. We talked a lot yesterday about the importance of the low friction on the web that makes it so easy for users to tap on a link and experience something new. That's so important for that really healthy reach that the web has. And one of the reasons that is true is because of security. Because users don't have to be afraid what's going to happen when they tap a link. And so sometimes that means we get things where it's like, we could have done this better if we would have shipped a whole native app. Well, yeah, of course. The security model is different. But that's one of the reasons the thing that enables the superpower of the web. So that's one of the ways I think of it. So you see it as a bug that native allows this sort of stuff to happen. I want to call it a bug. I'm just saying it's a different trade-off in terms of reach. Do you want to ask a question on the mic? Hi, my name is Adam. I have a question about the push notifications. So right now when the user decides to accept push notifications, the token is bound to a single device. And do you have some plans to synchronize it across all the browsers? Or when the user buys a new phone, that they don't have to sign up for the same notifications as before? So we've definitely talked about those kinds of use cases and tried to reason how to do that in a way that makes sense to users. And that helps them accomplish the things they want to do. One thing to remember, too, is that when a user chooses to enable notifications, it's often very tied to a specific device or context. So I might turn on breaking news alerts on my desktop computer, because I'm always looking for something to distract me during the workday. But I don't want to do it on my phone necessarily. And so you have to think very carefully about the different user contexts that you'd want to show it, not to say nothing of the security implications and privacy implications of that. We've definitely talked about it and are open, trying to figure out the best way to do that or protect problem. You could imagine a variety of approaches with Chrome synchronizing data already between different Chrome instances and so on. And like Alex said, I think this is something we've talked about in the initial cut. We want to keep it simple and focus on the single device case. OK, thank you very much. So we had one question in from Slack. Why does Jake not wear shoes? Answer is simple. Your shoes, you lose. Is VA actually paying attention to the use asm flag? Because it used to be, we were saying, we're going to make just all patterns fast. So have we changed our stance on that? Greg, do you want to take that? Sure, I can take that. So VA over the past year, actually more than a year, has been working on a brand new compiler that's called Turbofan. This is to replace the old one, which is called Crankshaft. Anyway, so Turbofan is a type of wear compiler, fully type of wear, which means that in the limit, they won't need to look at the use asm key at all. It will just be able to infer the types and then map it internally. However, they are using the use asm as a trigger to test Turbofan as it rolls out. And then once they have deprecated Crankshaft, then they won't look at it anymore. So push notifications for apps that have been added to the home screen, when you launch a window from a push event, they don't launch in a full screen window. Why is that? And is it something that we can change? Because it means you go from this nice native-like experience to something which all of a sudden looks very browser-based. Is there something we can do to fix that? Greg, should I take this one? I think that's a good suggestion. Currently, you can target the existing already opened window. So if the I2Home screen currently is one of the window is open in the background, you can still target it. So I think we should try to make sure even the, because I2Home screen, we wanted to work more like a native app. So I think it's making sense for us to be able to target it by the push notification, even when it's not running. From a standards point of view, this is something we've been looking at as well. It's just ideas that have been thrown around the room so far. But we've been thinking about something like a launch event in a service worker that will be fired if there's been a launch of a website done in an ambiguous way. And that will include things like clicking a home screen icon, clicking a link, clicking a link in the native app. And that will let you decide how to handle that. Should it be launched from the home screen? Should it create a new full screen window? So in the hope is to let you create single window apps or multi-window apps using this. And by ambiguous, I mean if someone long presses and says, open a new tab, that's not ambiguous. We don't want you to be able to disrupt that. But we want you to have control when the launch is ambiguous. Right, OK. We've got another question from Slack. Oh, asking for clarification on the asm bit. Does Chrome do ahead-of-time compilation like Firefox and Edge for use asm? I'm not sure about for use asm, but there is a snapshotting going on now. But I'm not familiar with the latest on what triggers it. I think it's async or defer on the script tag. We'll do that, I think. So I think we do it for work as well. So I think we're all very excited about Let's Encrypt. But Google isn't on the sponsorship list for it. Is it something we endorse? Is it something we'll be telling developers to use? Did we give it the thumbs up? Is it something we plan to sponsor? I cannot say anything specific about that today. But it's a project that we're really excited about and interested in. And that's all I can say today right now. Used to come on that. We're pretty excited. I said I'm excited, but we're really excited. We're pretty excited. We're pretty excited. And yeah, I think it's pretty damn excited. You see, if you put a big number to that, you'd have got a round of applause. Lots of zeros at the end. Stay tuned. So we've had a message come in from Seth Thompson, who was speaking earlier, PM of V8, saying, yes, we do have reader, real ahead of time compilation is coming for ASM.js. We didn't do it previously, but you can check that out on chromestatus.com for news of that. This one's written in another different font. Guys, you're winding me up. The name of what? Aerial Aerial. Oh, let's check it out. This is Alpha Slab. So this question is written in Alpha Slab. How will ES 2015 modules affect how we look at web components? So that's one for Dimitri. So the web components is a loose congregation of specs, right? And it's been evolving over time. It's evolved quite a bit this year. As modules get ready to be shipped on the web, I think there's a lot of interesting possibilities that open up for custom elements and imports. And I'm really excited about trying to figure out how the stuff fits together. And especially with imports, I sort of want to, I've been trying to pitch the idea that we should try to look at the loading mechanism that hasn't yet been fully packed out for ES6 modules, for browsers. And then maybe see if we can rebuild the imports on top of that and make something amazing happen there. Because the features that modules offer are quite tantalizing for the whole scoping thing is amazing, and the whole export stuff sounds really good. So let's go figure it out. Follow public web apps. No, don't go there. But there is GitHub for W3C web components. It's a pretty active discussion. So lots of interesting conversations there. Oh, would you look at the state of that? This is horrible. It's like reading a kind of, it's like a ransom note. It's starting to look like. OK, so we have a. I watched you changing that around, though. I think. There's a kind of fight going on. I'm trying to change it. Oh, we've got Comic Sans going on now. Thank you very much. Excellent. So yes, this question is written in Comic Sans. TC39 has discussed the possibility of adding types in future versions of the language. Is TurboFans type support ready to support this possible feature? Yeah, there's definite interest from us in working on this. I mean, we are working on it. Was there anything else beyond that? It was just that, yeah, is TurboFan got some kind of type support in there? Yeah, it's fully type of wear. So it's actually, it's like a perfect fit for it. So it's another one from, this is from Unfunk on Slack. Oh, can I? Oh, sorry. I'm staring too much at the, trying to decode the fonts that are going on here. Yeah, I got you. What font is your question going to be in? I think I'll pick the hell of a ticker, of course. OK, my question is, I'm Johan. So I'm building games using SML5. And the problem for me is actually how we can hide if I want to post the score. For example, I built a Temple Run and I got the score of the player. I want to post it to the server. But the problem I always face is like a people can just open the DevTools and then just throwing the same request to the server from the JavaScript console. And then they can manipulate the scores. Well, I mean, surely this must be something, the same problem that native games face, right? Because the code, you can always just put a listener on the wire, something like Wireshark, and see the request being sent and find out where the score this is. So is that the answer? Well, it's much longer, right? I mean, sure, you can also decompile Java, sorry. I mean, using the native is, you need another tools, right? Can you add a digital signature to the score and then check that on the server too before? And if it's errors, you're like, well, someone's doing some kind of manipulation on it? One idea also comes. Like a Mac, like adding a Mac to it. One idea also comes to my mind is it possible using a WebSocket to connect between, so it's not using the post request? I think you probably still want to add some way to authenticate the actual score. So adding a signature for it would, I think, help with that, because they could still tamper with it in your client, in your game. OK, cool. Thank you. So we've got a question from Unfunk on Slack. What's the best way for developers to provide feedback and make feature requests, not just to Chrome, but also other browser vendors and standards bodies as well? Anyone want to be brave on that one? Standards bodies? So I think this is a good question. I don't know if there is an easy way to go and stuff. Like, I would like to propose a feature, because there is definitely W3C, which is not the easiest working group or group of people to work with. But I think, did somebody make a face? But I think there is definitely more and more opportunities for developers. I'm going to tout hours, which seems to have worked really well, and this is just blink depth. I think there is a lot of developers listening there, and sometimes just putting an idea out is a good start. And I think, as a community of browsers, we do need to get better at engaging developers collectively rather than separately. So I'm going to make a pointed look at Darien and Rahul there, because this is a Chrome Dev Summit, but there is people from Microsoft here from Mozilla. It's a great opportunity, and you're all here, right? So it's a great opportunity, and we need to get better at this. Yeah, there's also the YCG, the web platform incubation group. That's a great place to propose new things or take problems, too. And that's something we at Google use ourselves. The background sync specification is part of that movement. So what I would always advise, if you're thinking about a new platform feature, try not to think about solving just the one problem you have, but what are the parts of that problem and can we create them all so those could be used in different ways to solve other problems as well? Because designing a new web platform API is really, really challenging. There's all kinds of security considerations, other APIs in the platform that you have to fit within, other semantics that aren't immediately obvious. It does require a fair bit of effort to drive into it. However, you'd be surprised a number of times that browser developers and on standards lists, people were making arguments in complete vacuum. And there's developers who actually have very concrete use cases. They've got numbers or examples in the wild that would really help for those conversations. So I think looking for places to give that concrete feedback really helps the process. So this is actually an issue that's been bugging me recently. When pages are launched from the home screen and full screen, the user loses access to the URL bar, which obviously impacts the being able to share that page or that app. It feels like we're kind of losing one of the core features of the web. Do we have any ideas, any solutions for this? Alex, do you want to take this again? Yeah, let's see. So Flipkart just had a session where they talked about how they put different navigation controls inside the experience once it's added to the home screen. And that is something important that you have to reason about. For example, remember last when we had IO this past IO, we had this awesome IO web app that, when it was on full screen, people would be looking at details on a session and be like, how do I share this? Because I know it's got a URL that makes sense. I can share it with people, but I don't know how to do it. And we were like, oh, that's a really good point. How do you do it? And so it's important when you're reasoning through this to think about those kinds of affordances. We're also trying to look into how best to support that. So actually, Paul Kinlan's got a great post on his site that explains a way of doing this, triggering a native share intent. But it's something that you do have to reason about if you're hiding this browser UI that we've just taken for granted. Do you want to ask a question? This one's a little silly, so I'll make it quick. I was wondering if you guys knew of any benchmark that would work really well in my Nexus 6p, where I could beat an iPhone 6s. I mean, just anything, any place I could go where I can compete with my friend, not Paul. You can already use your 6p to beat an iPhone, just actually physically beat it on the screen. That's about all I could do. And then your friend's iPhone will run a lot slower. How about loadflipcart.com? What was that? loadflipcart.com. The best benchmark is something that affects users, not in a vacuum. Will I win, though? Have you tried that one out? Because if I, if he's going to see this, and if I lose at this one, too, it's really going to be embarrassing. So an app that I built, I can plug loads of things. It's great. SVG OMG, which is a kind of SVG optimization thing. Once a service worker is there, you revisit that. And that loads in 100 milliseconds flat. And that's using service worker. So on devices that don't have service worker, especially if you're on something like 3G, which is 1.7 seconds worth of connection setup, that's what it's going to be on an iPhone. So find somewhere with 3G or 4G, and set, especially the second load, or from a home screen launch of SVG OMG on both, and you will win by almost two seconds. So I really got to game it to win. So I think what Greg was saying is benchmarks are really finicky, depending on the precise characteristics of the device and what kinds of just lots of different things. So that's why I want one where I can win. But that's why I think that Raelle is an interesting way of looking at it. What ultimately matters is the user experience and performance. And that allows things like service workers and other things that have a really important impact on them. Yeah, and I wouldn't say loading using caches and things and service worker. I don't think that's gaming it. I think that is what we want the future of the web to do. We want when users go back to something they're used to, that it appears instantly. And they see content that, or maybe even in future content that they haven't even seen yet using background sync and things. And yeah, this is stuff that Chrome is waiting on. So Google's given us slower devices so that we can be better developers. Is that what it is? Is it? Is it slower? It's definitely slower. It's definitely slower. I mean, just raw JavaScript performance. It's a lot slower. Well, it's Android Dev Summit, isn't it, soon? Is that next week? You can take that one to the end. We've got a question from Slack from Tim Cadillac. Data saver is awesome and necessary. But it's understandably bypassed on HTTPS, making it conflict with the security everywhere goal. Both are super important. But what's being done to balance security with the fact that many people need to use these proxy services for speedy access. Prisa, do you want to take this one on? I did say the word security. This is about data saver. This is data saver. It doesn't work over HTTPS, understandably. Should it? Or is it something that's going to die out as we push HTTPS across the web? Is data saver. It's a hard question. So we have a long ways to go for all of the web to have full HTTPS adoption. So it would be nice if I could blink and say that that's going to be a problem we immediately need to fix today. And my kind of hope is that actually the needs for data saver are going to, at the same time, go away. And you look like you have something in your tongue. No, no, go for it. Finish, finish. And I'm hoping that HTTPS is going to get faster. Networks are going to get better. Our performance on bad networks is going to get better. And the need for data saver will at some point not be there anymore. So we're thoughtful to this. I think we are really, I care about HTTPS. I also care about people being able to use the web in networks where I recognize that it's not a experience that actually impacts things. So I think we're exploring how to make this better. The real promise of HTTPS is the endpoint security. And so we really are being thoughtful about that. Yeah, also note that data saver currently is implemented as a proxy service, which is why all these thorny questions come up. You could imagine that the same transforms could be applied at the origin server. I'll mention briefly paid speed, which does some of this work. So you can imagine other ways to solve this data compression problem without running into a proxy service dealing with HTTPS. In addition, just designing the web application to be smarter about how it uses the network. Flipkart's a great example here. Leveraging service worker, being smart about the initial payloads, being smart about bringing down content only when needed and in the background caching it and so on. All of those things really can pay off here to the point where, as Prisa said, feature like data saver isn't really needed. And so data saver is really there as a tool to help users access the web as it exists today. But as developers, we can all change the web. We can evolve it. We can make it better. We can make it so that things like HTTPS work great. Yeah, and I think to maybe one, I don't know if this was implied by the question, but why not just have data saver support, HTTPS? And that's a challenge as well, too, because as Rahul said, it's a proxy. And SSL offers that end-to-end connection. And we, as Google, don't want to interfere with that. You know, it's, yeah. Trainhouse River Skull and Crossbones. That question was written in windings. Thank you very much for people operating that document. We have a question on the mic. Can you speak to us specifically about service worker and security for, say, like a banking application or retail as well? Is it just tell the security folks it's HTTPS, and we can just be OK with that? Well, if your bank website is not HTTPS, then leave that bank. It would be my first advice. I don't work for a bank. What security issues are you concerned about with this? I work for Target. And they had security issues. I think everybody knows about that. But so in order to utilize this, which we're planning on, what do we give to the security folks? Because they've never heard of it before. So they're going to have questions about it. And in large corporations like that, it can take months and months for those people to catch up to these things. Could there be a white paper that says, here's what you need to know right now? It's a great idea. Yeah, we should do that. Yes. I'm looking at Alex Russell. He's writing the white paper up as we type. But he's the service worker security person. Yes. It'll be done probably by the end. And we've got time. I'll meet you at the front door. Yeah. We have another service worker question here. Exciting possibilities with service worker. But is an empty app shell a sensible starting point to progressively enhance from? Is there a strategy to better avoid serving a page without content until JavaScript successfully intervenes? That's from Phil Hawkesworth. Thank you. He used to be my boss. He could have asked a kind of question. Is there anyone want to take that? I mean, I could take that. I'll take that. Serving the app shell, I mean, currently, using the app shell approach, you're going to get a result much quicker than you would by going to the network, even with server rendering. And we've proved that out. One website you can look at is if you search for offline Wikipedia as a demo I built. And you can sort of set different flags to serve a render or not serve a render or use a service worker. And you can put those results through web page test yourself and see what the effects are. But one thing that I'm excited about, and this will start landing early next year, is streams arriving within the service worker. These are streams that you can construct yourself. And the technique I'm really looking forward to using is where you would serve the header of the page, including like a kind of first render tool bar and things. So you can serve that from the cache and then start streaming content from the network. And if that stream takes a while, you can start serving a different stream. So in that model, your service worker becomes the server and you are serving one response with HTML in it. And I think that's a really interesting pattern. That's something that Wikipedia have expressed interest in, because it matches much closer what they do on the server. And they can start sharing code between the server and the service worker. You have a question? Do you want to? So most web technologies that we've worked with have the ability to do some degree of progressive enhancement, but service worker is very much a, your browser does it or it doesn't. How would you suggest building an application that needs to support browsers that don't have service worker without just writing the application twice? Yeah, do you want me to do that again? Oh, I'm going to speed. I mean, I'll just add a bit here. Actually, I think I feel like service worker was designed to be very complimentary. Like, you can take an existing web application and add on a service worker that's going to be able to intercept the network requests that your page makes. You're not having to rejigger your page dramatically to start benefiting from service worker. Of course, you can go even further. But like, compare that to sort of other techniques like using AppCache, where you really did have to be redesigning the way your page worked. Or if you were trying to use local storage to serve your resources and XMLHP request to fetch them, there you're very much redesigning your page for that technology, that sort of serving architecture. But here, you can take an ordinary web page with URLs and start to capture them into caches and so on. I guess I'm talking less about the case where you're just using service worker as a caching acceleration mechanism for resource requests and more the additional features or additional logic that may get pushed into service worker. I mean, push notifications already use that. Other things will start using that. I think that's a good point. And you can imagine that you might want build a framework that allows you to take some of the code that would demodularize so the code that you want to have in the service worker could also run in the main document when you don't have the service worker as a context. But some of that's probably things that these patterns are things for us to figure out, I think, for this as a community to figure out. Yeah, all of the examples that we saw over the last two days using service worker, they work on browsers that don't have service worker. They just work better on browsers that do. One of the best examples that I've seen of this is at Google I.O. 2014, the talk that you and Alex gave with the Game of Thrones. I think I know where it was at Harry Potter, I don't remember. Anyway, you guys started out with? Big difference there, Greg. Sorry, I don't know either of them, but. Full of a toke. Yeah, that's true. Anyway. I'm so embarrassed for you. So where you guys started out with a non-service worker site, and then in the course of over 20 minutes, you converted it into offline, cacheable, and everything. And it was really, really magical to see, actually. So you can go back and stream that off of YouTube. And it is possible to create a site that depends on service worker. But we made it so you would have to jump through hoops in order to do it. The thing you served from your server would be a loading page. And then you set up the caches in the service worker. And then once they're ready, you refresh the page. And then it can intercept it and serve something different. But we've made that deliberately difficult. But you can do that if you want to. But I will hunt you down, because I don't think that's the right way to build websites. We haven't had a question on the microphone. Yeah, this time about service workers. So how service workers caching the app shell and serving the content via API have to do with ICO? How it's going to work with ICO? Is the search engine will see the content in this case? How's about the app visibility? I think it's a very similar answer to before. If you're using service worker as enhancements, the user lands on the page. And you're serving content. And then on the next load of the service worker, you can do things with the caches. There, in terms of how Google's web search sees your site, it's exactly the same. And there's no SEO impact. Yeah, if you start making things depend on service worker, at the moment you will impact SEO. If we see a lot of people doing that, then we'll look at ways of fixing that. But there's nothing in there at the moment. OK, so basically it's all about progressive enhancement. Absolutely. Yeah, service worker was built with progressive enhancement in mind from the start. The first load of the site that supports service worker doesn't use service worker, right? Right. So there's going to be a breakout session on service worker after the event. And I still have a little bit of energy left, so I could probably do a Q&A on that. So I'll kind of wait. Why don't we take another service worker question? Yeah, you guys are getting off lightly with this. So when we'll add to home screen the on desktop is a question we've had. Because it's really annoying that mobile is pushing forwards and the desktop is being left behind. Rahul, do you want to take that one on? Sure, I can take a stab at it. We are looking at it. We are experimenting. On desktop, I think it's different from mobile in the sense that on mobile a common user pattern is going to the home screen, launching an icon. And so bringing that to the web, I think was a reasonable thing to do because you're in the user flow. On desktop, it's a bit more of a mixed bag. There's much more established patterns of behavior. We need to be thoughtful about how we want users to change that behavior. And so we're looking at it and we'll figure out, we'll try some things out and we'll see how they work and then make progress. Since the beginning of Chrome has had a create application shortcut feature, which is essentially add to home screen, it's just not something that we are promoting in the same way that we're promoting on mobile where you see the banner show up and so on. But as Rahul says, it's something we're looking into. So I'm aware that I keep saying guys when I'm referring to groups of people, so I apologize for that. I'm going to blame being in America because I don't do that back home, right? I always say folks. I say folks. Something has gone very wrong in my brain, so I apologize for that. Another question. Angular is the largest front-end framework currently. Why does the Chrome dev team not include them more in demos? You would increase your target reach audience by several orders of magnitude. Matt should probably take that, right? Yeah, exactly. I've got a minute and 18 seconds to do this one. So yeah, so I've been doing this for a really long time. We've been in the web UI world for a really long time. So you see a lot of patterns emerge. So there's always about every two or three years, one or two years. There's a new hot thing that everyone sort of gets excited about. So right now, it's actually probably react more than Angular. I would say Angular is probably the last one a couple of years ago. And honestly, from the web developer's perspective, this is great. These are all great choices on the fact that you actually have a choice on the web as opposed to native is a really, really good thing. And you can find a framework that actually really suits you. And that's really awesome. And I'd much rather someone build an app in Angular than build a native app, frankly. I really want the web to win. And from the perspective of framework developers, like I was one previously, the web platform is this thing that doesn't really do what you want and that you can never change. So they build all these big abstractions and bring their own platform and bring their own programming model to the table. And it ends up being kind of an interesting thing. And it ends up really, really successful. And part of our job in Chrome is to make those things run really, really fast. But Polymer's pretty different than that. And when we first showed up to work on Polymer before it was known as Polymer, Darren and Dimitri sat us down and said, OK, here is these new primitives, web components. You have to make something out of this. It has to be idiomatic. You have to use the platform in the most idiomatic way. And it has to be really, really thin. And if something's broken, you have to tell us so we can fix it. So that framework assumption was incorrect for us. We were actually allowed to change the platform. We were part of the platform. And so what happened is Polymer ended up being very different. We used DOM as the framework. We don't build a whole big framework. Apps built in Polymer don't have a really big JS payload. And they're really, really fast as a result. And we can innovate on them on a native level. So when they end up, Polymer was ending up just kind of an extension of the native platform. And it was part of, and we're physically part of the team as well. So I think it ends up that's why Polymer is different. That's why we're part of the web platform. That's why you see us here. That's why you see us at IO. And that's why we're focused on it. And that is all we have time for. So thank you very much for the panel. Greg Simon, Darren Fisher, Grace Skloba, Rahul Rol, Roy Chowdhury. Oh, god, I'm so sorry. We're the third and some other people. Dmitri Glaskov, Alex Komorowski, Matt McNulty, and Prisa Tabriz. A big hand for these folks. Thank you very much. Thank you all for being here.