 So, good evening. I'm Chris Wilson. I'm a developer advocate on the web platform at Google. And I've worked on the web platform for a super long time. I actually just had my 23rd anniversary of working on the web platform. And I have to say this is one of the most exciting times in that history because progressive web apps are an amazing breakthrough in user experience. Like this lets you build stuff that really just works for users. And this is the first time I can actually say that and not kind of grimace a little bit inside when I say that. So, I hope that we filled your heads with a ton of really interesting stuff today. I hope that, you know, we've given you a lot of grounding of what you can build and how you can go about getting started. I hope we've impressed you with the opportunities both in market opportunities and as Tal just talked about in addressing emerging markets, which I think is a really great opportunity for the web as well. So, in this talk, I want to discuss a few areas that are still kind of under construction. This isn't stuff you necessarily want to be putting into production today. A couple things in here are but most of it is sort of to spark what's going to come next in the future. So, this is kind of the next, next level of user experience. And if you saw my Google I.O. talk pretty recently, what's next for the web, you might think this is just a replay of that and it totally is not. This is not a whirlwind, deluge, eye chart of new features. I actually just want to focus on three important challenges that are relative to progressive web apps. First and foremost, knowing who the user is, a.k.a. authentication and sign-on and enabling the user to pay for things on the web, which would be kind of nice. And finally, connecting with hardware, which is kind of near and dear to my heart personally. But I'm going to talk through some developments in each one of these and starting with knowing who the user is, a sign-in in particular. Now, let's take a look at an average sign-in screen today. Like, this is what users land on most of the time. And they often have a lot of problems with this. I know I do because every time I go back to a service, I can't remember did I sign up with this with my Google plus account, did I use Facebook, which e-mail address did I use because I have multiple e-mail addresses. All I want to do is get to the application. And of course, my favorite button on this entire page is forgot password. Is there anybody here who's never used a forgot password button? Oh, you're my hero right there. Okay. Or you're lying, which is actually not calling you a liar. But anyhow, on top of that, mobile devices, which of course a lot of browsing has been moving to mobile, it's really, really hard to type. Particularly things that are not, you know, words in your preferred language. And especially when you're using different characters like you do in a password. I know, for example, I have optimized at least one of my passwords to have characters that are more easily accessible on a mobile device screen. So I don't use Tildes in my passwords anymore because it's two extra taps away on an Android on-screen keyboard. And I'm sure you can understand this leads to a problem. I'm sure some of you know what this is already, so just call it out. What do you think this number is? Most commonly used password. That's right. This was the most popular password in 2015. It edged out the previously most common password. Password. And of course, you know, this isn't even getting into how many of us share passwords across different services. I mean, I mean, how many of you share passwords across services? Because I would never do that. The point though is the complexity of remembering passwords leads users to use weak passwords or to share them. And that, of course, is a significant security risk. So Chrome and pretty much every browser out there try to encourage stronger passwords by using a bunch of characteristics to automatically detect when you've signed in successfully and prompting the user to save it. And then auto-filling it when the user returns to the site. You don't need to remember to, you don't need to type anything. Hopefully this will just work. And Chrome actually also has, and several other browsers have features that will synchronize that across different devices as long as you're signed into Chrome. And in Chrome for Android, this also applies to Android native apps. So Android native apps get the same password data. But even just Chrome's password manager alone assists 8 billion sign-ins a month. Like 8 billion times during a single month is how many times that saves somebody from typing in a username and password. Now, to a large extent, this should just work. Like you shouldn't have to do anything. I should have stopped talking about this like three minutes ago. But since this is auto-detection, this is guessing. It's best to give password managers hints so that they can guarantee that their password forms are being treated properly. The best thing is, of course, that these hints actually work across all modern browsers. This isn't Chrome guidance that I'm giving you. This just kind of works. So despite this talk being mostly about what's next, go do this right now. Since password managers are heuristic based, sometimes extracting that semantic information is difficult. Just give us a hint. Like here, we can't really tell what the username is. Is it display name, phone, email? So you can solve this simply by putting in autocomplete attributes. Username and password. And if you're marking up passwords, use current password. Because when you have account creation or changing password forms, you can use new password for where the new password is going. And this has two effects. I'm only mentioning this because there's one really interesting one. The first boring one is simply this prevents password managers from plugging a password you already used into a new password field. But when you mark up your forms with new password, the browser can also tell that you're trying to generate a new password. And you can do it for them. We can go ahead and just auto-generate a password for you. So instead of a password like this, you will get this. Well, not exactly this. Don't write this down or anything. Something like this. We've been experimenting with auto-generating passwords in Chrome for a while. It's actually in Chrome canary, Dev and beta channels. Hope to deploy it to stable soon. But if you properly mark up your fields with new password, it will make this possible. We'll be able to do this and other browsers will too. But setting aside that stuff, what's really next generation for sign-in is using something called the Credential Management API. Now we've just shipped this in Chrome. It's still kind of early days. Certainly not implemented across all browsers yet. But the Credential Management API gets you away from using form fields with wacky auto-complete properties attached to it and lets you integrate more deeply into the sign-in process of the browser. So you can also, by the way, use this to sign into federated services, which is kind of hard to do in a form. So AliExpress, which I think we talked about earlier, is actually a really great example of a user flow because it's a shopping app. It's really important for users to be signed in right away to ensure that if they have items in their cart, they're still there. If they have preferences or stuff that they've been looking at or wish lists, it's already there. But at the same time, you really don't want to force the user to log in as the first step. Like, you don't want to take that active step of saying, okay, give me your username and password before I show you anything. Because if they're a new user, of course, they may just want to browse. Or I may just be searching for something new. I don't want another step in my way. So with AliExpress, when a user launches from the home screen, it loads up this app shell and during the startup, the app asks the browser for the user's credentials if it can get them without bothering the user. And then they can sign the user in. You can see this at the bottom here. And they don't need to ask the user at this case, in this case. Now they do this in the credential manager API. And the code for this flow is really pretty straightforward. There's just a navigator.credentials object and you have a get method. You can ask it. You pass it in some options. You say this is a password-based credential. And most importantly here, I want this to be unmediated. I don't want to prompt the user from this call. So this code is actually safe to put on every page in your app to try to trigger sign-in because it won't ever interrupt the user's flow. It won't ever pop up a dialogue. It will just fail if it can't do it automatically. Now auto sign-in is kind of new for the web. We're starting out pretty conservative. So the browser will only hand over these credentials if the user is turned on automatic sign-in. And if this user only has one credential for the site. If they have multiple credentials, we don't want to pick for them. We want to make sure that they get to choose. And of course this would be an interesting security place. So we need to make sure it's kept secure so credential manager API is restricted to secure contacts like many new features. And passwords are never actually directly exposed. Like when you do get what you get back as an object that has the password, which you can then hand a fetch to post to a same site endpoint. And it has to be a same site endpoint. You can't be pushing this off to other sites of course. So once you get these credentials, when you actually want to sign in, you call fetch and pass it in a post. Now, when automatic sign-in isn't possible, credential manager API can still offer a one tap login. It can still say I want to sign in and then trigger a chooser dialogue. So the user can enter new credentials or they can pick between multiple credentials that they have. So Chrome will present an account chooser like this one. This one only has one available. But if you need to do this, you use almost exactly the code that you saw a minute ago. The only difference is there's no unmediated in this. So you can use this flow when the user clearly has an intent to sign in. Like if they click the login button, then obviously you can run this. So this is all great. You actually do need to forcibly store credentials. And this is where our heuristics often fail. But the credential manager API actually lets developers have the ability to choose when the save your password prompt is triggered. So Chrome isn't going to miss out on when the right time to trigger this is. So if the user has just entered their credentials into a form, you just create a new password credential and tell it to store. That constructor will deal with parsing your form, pulling all the fields out, that kind of stuff. And you can use this, as I mentioned before, for doing federated login. Google plus, Facebook, any other federated login. You just have to create that credential using whatever whatever that particular federated credential wants to use as an ID and a end of provider, so an identifier. And then the browser kind of just deals with the rest of the process for you. And finally, of course, we can forcibly sign you out. We can say, hey, don't ever automatically sign me back in. Always prompt the next time that you call the credential manager API to do an automatic sign in. So a number of companies are already using credential manager API or started working on it, in some cases deploying this in bits and pieces. You can play around with these today in Chrome, because we shipped this in Chrome 51, so it's actually turned on already. But now I want to move on and talk about paying for things. Now, obviously, we've been able to pay for things on the web for quite a while. And it's no surprise that given the rise of mobile computing, a majority of commercial traffic is coming from mobile devices like this one. What is surprising, though, is that 66% of purchases are actually happening from the web on mobile devices. So by and large, users are using the web to purchase things more than they're using native apps to purchase things. So I guess the web isn't dead after all. But unfortunately, there's a lot lower conversion rate, too. And conversion rate is a weird concept, so I want to make sure that I sort of capture the 66% fewer conversions equates to, if on average, you make three euros per visitor to your site. Now, on a mobile device, you're going to make one euro per visitor on your site, on average. Like, this is pretty bad, right? This means mobile users are not paying you as much, or they're not spending as much on your site. Now, if you wonder why, I think the answer is actually pretty simple. Because checking out, particularly on a mobile device, is still a pretty messy project. So checkout forms have improved since the beginning of web commerce, of course. But fundamentally, it's still kind of the same thing. I still have to manually input my credit card info, my billing address, my shipping address. This has gotten so bad for me personally, by the way. I get really, really excited when I go to a forum and they have put the zip code first, and they automatically fill out my city and state for me. Like, I'm so excited that they do this, when if you back up for a second, I shouldn't have to enter any of that. Like, it should just know what that information is. And of course, this is worse on mobile devices, too, because, you know, if you thought typing your email address was bad, try typing a 16-digit credit card, especially when they forget to label the field properly, and it gives you the QWERTY keyboard. Yeah, it's a mess. So, just like with sign-in, our first step to solving this problem is autofill. Now, autofill works on existing forms. You don't have to modify your site, although it does actually do the same kind of auto-complete types. But stores the user's address and credit card info. You can manually save this in settings yourself. You can let it auto-detect it. Chrome will synchronize it, just like with user sign-ins. But, so autofill is great. I mean, it does actually improve the problem. It raises our conversion rates about 25% on an existing site with no changes. But, although autofill gets rid of the manual nature of data entry, it does make it simpler for the user, but it's fundamentally the same kind of existing checkout flow. You're still handing the user the same form. It's just they have a stamp for parts of it, and they just have to make sure they end up in the right places. So the web checkout process really needs to be kind of reinvented overall. Now, like I said before, the current checkout process is really pretty form-heavy. For users, though, the ideal experience would really be the server just works it out with the browser. Like the browser is your user agent. Like, that's why we call it a user agent. It works on your behalf. So, sites should be able to focus on creating an amazing and engaging shopping experience, and not so much on that last set of pages that you have to navigate through that has a long checkout form. So, this is where web payments comes in. With the payment request API. So, payment request is a simple JavaScript API. It allows the browser to handle that heavy lifting of payment collection and give the user a one tap checkout, but still make sure that the site is going to get the right set of information, not the wrong set of information. And the user has explicitly said, yes, I want to pay them this much money. So, this is an openly developed standard API. No matter what browser or platform or payment method you choose, everyone should be able to pay without a checkout form in the end. We're still working on this, but obviously we'll come back to that. This is under development in the W3C web payments working group. That group's goal is to create a universal, so cross browser standard for any website to accept any form of payment. So, this isn't a Chrome only API. We want this to be supported across all browsers. In fact, I really want to give a shout out to Microsoft because they've done a ton of work in the web payments group as well. Hi. Some love. All right. And although we're targeting mobile first with Chrome's implementation, because that's where it's most impactful, payment request is explicitly designed to not be tied to a given platform. The goal really here is to create an open ecosystem where any website can accept any form of payment with minimal code changes and without any proprietary one-off payment APIs. So, with Autofill, we can eliminate that manual and tedious bit, and we can also create a manual and tedious bit. Our implementation actually uses the same data from Autofill too, so you won't have to enter your credit card details one more time if you've already done this. And since the browser is taking care of the steps of collecting the right set of information, we go from having multiple taps, multiple forms to just one. You just have to approve it. So, the flow here is really the site initiates a payment request. The website passes to the browser what it needs for that, so it says how much are you charging? What set of items do you need? Then the browser determines the intersection of what types of payments the site supports and what payments the user actually has, what payment methods. And then presents a selection UI to the user to choose which kind of payment app. This can be anything from a credit card to an installed payment app like Android Pay. And then the browser gets a response back on this and returns it to the merchant. And the website, the merchant's website now has everything they need to process the payment, so credit card info or the right set of tokens. So, looking at this in code, I know this ends up being kind of small because it has a lot of information on it, but the real this is by the way based on the first published working draft, this may change, so like if you go back at this slide in a year it's probably not going to be totally right on, but we'll see. When you create a payment request, which is the first line of this, all that you do is the first parameter is an array of what supported payment methods the merchant supports. So here they'll take Visa MasterCard Amex Discover, but that's all. Not any other credit cards or other apps or anything like that. Now, the default here is this, right? It is using credit cards to pay for things, because that's kind of still where we go. But they also pass in the line items, the set of things you're paying for, whether they want shipping options so the website can actually support those shipping options and negotiate them later, and then update the total price. Now, I did talk about payment applications. I wanted to describe this in a little bit more detail. So Google launched Android Pay late last year not late last year, early last year and we've seen phenomenal growth in people using it to pay for things on Android devices and with merchants physical merchants. But what makes this even better than using your credit card using your credit card directly I should say, is that it uses a tokenized version of your card when it passes it to the merchant. So they can't reuse your card information. And of course it uses device authentication to protect your transaction. It knows it's using your phone, it's not just a credit card number. So let's take a look at Android Pay. All that you really do is you have the same payment request creation, but you give it a different supported type, a different supported payment method. And here of course Android Pay has some app specific parameters. So it tells you what gateway it's going to use, what key it wants you to use, what version of the API. And of course that would be different for different types, different payment apps. So you can get started with this today. It actually is supported but it's in Dev and Beta builds of Chrome for Android. It's behind a flag until we launch late this year. And then we plan to add some more platforms including desktop and the ability for third party payments, so other payment applications to register with Chrome in 2017. So we've been working with a large set of partners on this. They've been testing this kind of improving it. I explicitly put this up because I wanted to prompt people if you're interested in this, it would be great to share feedback on it for you to play with it, talk to us, talk to the W3C's working group, because I think that they want to get to a great place with this API. Okay, so now you've got users who are logged in, they can pay for things. The final area that I really feel unlocks the potential for progressive web apps, for the web as a platform is connecting to hardware. Now, the web of course already has access to a lot of hardware devices, accelerometers on my phone, game controllers, camera, audio input, audio output, MIDI devices, lots of other stuff. But I want to focus on one area that we've been working on lately, which is Bluetooth. Now, when I say Bluetooth, I'm not talking about headsets, I'm not talking about mice, those are Bluetooth devices, but I'm talking about things like heart rate sensors. And the latest major version of Bluetooth, version four, which is actually like six years old by now I guess, introduces this thing called Bluetooth low energy. Now I'm sure you've probably heard Bluetooth low energy, but you probably don't know why it's really exciting. But the interesting thing is that it's also really weird, because unlike other tech, like Wi-Fi or Ethernet, which consistently increased their bandwidth, version over version, if you look at Bluetooth on the right-hand side here, version four seems to have fallen off a cliff. Like, why did they go from the transfer rate of 54 megabit to 1.3 megabit? Well, the answer is actually pretty straightforward. It's power and cost. Bluetooth one, the Bluetooth creators wanted to evolve Bluetooth into a technology that could be integrated into thousands of devices, like dozens of devices that you would use on a daily basis. And when you do that, you have to make sure that it's trivial to pay for, you know, trivial cost up front and it's trivial to maintain and it's trivial to fund the battery. Like, continue to keep it powered. So when you look at this end to end, it comes down to batteries. And batteries are frequently something like this. It's a CR2032 battery. Like, this is what actually powers the clicker that I usually use. It doesn't provide a ton of power. Like, this won't power my laptop for very long at all. And this explains why the transfer rates are so low because it needs to consume less power so if it runs at a slower rate and runs the transfer at a slower rate, it'll save a lot of power. Now, you don't have to worry too much because most of the scenarios where you're going to use Bluetooth, you're not trying to push 4K video through this. You're pushing control instructions for racing cars or you're pushing data for a Bluetooth LE printer or you're controlling BB8 because this is actually a Bluetooth remote control robot. There are also devices like this. I actually have one of these up here. This is a DOTI LED notification display which you can have this display anything you want. You can put custom patterns on it but you can also set it up so that it flashes red when something bad is happening or whatever. I usually have this sitting on my desktop and doing weird stuff. I want to take a look at how this works in practice. I'm going to start with a little demo here. I have a Bluetooth LE device here called a Playbulb candle. It's a mood setting LED candle so we're going to bring the mood in here. You can buy these for about 20 bucks online. You can actually buy them a lot cheaper if you buy them in bulk. But the cool thing about this and you can tell already is that it changes color. It's a LED. Let's switch over to the remote here. Let's pull out my phone. Sorry, I have to leave the light off on this because the color actually shows up then. I'm going to open up my demo page, connect to the device and it asks me what I want to pair with so I'll tell it the candle. From a web page with JavaScript I can directly control the candle. Kind of cool. The candle actually, it has a few other things in here too. I can set modes in it so it flickers a little like a real candle. It flashes or pulses or does the rainbow effect which personally I tend to think of as the seizure effect. But let's turn that off. Now, the really cool thing though we actually just put this up a few days ago is this has a sensor in it. There's a tiny little hole you can't see it from there. Can't even see it really in the camera but it's a sensor for when you blow the candle out. I'm going to blow the candle out and watch the screen instead. Oddly you can blow it back on too which is kind of strange. But okay. Let's go back to the slide deck. Before I dive into the code I need to give a few basic terms from Bluetooth. There's two roles in Bluetooth. The central device, my phone, a peripheral device, the candle and this weird thing called GAT. And GAT is how these things communicate. It's a generic attribute profile. The peripheral device has what's called a GAT server and that basically lets you ask it questions about what kind of services do you provide what characteristics do those services have and let you read and write those values. So yeah, that's pretty much what I said here. So basically each service contains one or several characteristics can have multiple values. Some of these are standardized, like battery service to tell the battery level is a common thing. You can query any device that supports the battery service how, you know, what level is your battery at in a consistent way. Now I want to run through some JavaScript code super fast to do this. We actually have a code lab on how to do this. We have a number of the devices here that you can play with tomorrow if you want. But in general you just call Navigator Bluetooth Request Device. You pass it some options that let you filter what devices there are because there's tons of Bluetooth devices around in most common scenarios today. And actually this filter list is not optional. You have to filter it down somewhat. You have to say you know, named Playbulb or I'm looking for something that supports battery service or something like that. So that's what this example actually does. It looks for anything that supports battery service. Once you've selected a device, you know, once we've popped up that dialogue the user has chosen to pair it, you have access to a Bluetooth device object, which you can connect to the GAT server and you can ask it what it supports, or you can ask it for a specific service. Two things that I should note here. One, when you request the device to begin with, it has to be inside a user interaction, like a click on a button. And secondly, of course, like all powerful features in the web platform now, you have to do this from secure HTTPS pages. Works fine on local host too, of course. So then you can get services and characteristics. So here you get the service, the battery service, the battery level, read value, tells you what the battery percentage is. Pretty straightforward. Writing to services is actually just as easy. This is the code to write the color to the playable candle. So you start out, you request the device, you connect to it, you connect to the candle service, you connect to the candle color characteristic, and then you write it, like you write a value to it. So this is pretty straightforward, although you're probably asking, wait a second, this is magic candle service UUID values and candle color UUID. So it's possible your Bluetooth device comes with the programmer's guide. Some of them do. You can actually get one for the DOTI. But if not, you can also install whatever their control software is, like there's a playable candle app for Android, and then enable the developer option in Android settings that lets you snoop on the packets, and you can tell what characteristics and everything you're using. Now, to be notified when a characteristic changes, like when I blew out the candle, all you have to do is add an event listener on when that characteristic changes. Whenever the characteristic value changes, the event handler gets called. I did, by the way, want to briefly connect Web Bluetooth with another project, the physical Web. So physical Web is about beacons, low-cost Bluetooth devices like this, that just broadcast a URL, like Bluetooth devices broadcast their presence anyways. These broadcasts specifically a URL. So people in the first few rows, you may actually be picking this one up. But the goal of them is to make interacting with smart devices as simple and fast as possible. So as long as physical Web is enabled on your phone, you will actually see physical Web pages are nearby, and they get filtered by a Web service. This won't be too spammy. And the train that you're on can actually broadcast the link to their schedule. A parking meter can broadcast the payment app. A dog collar can broadcast its owner's contact information. Now, in the future, though, this is the cool part, this is why I'm connecting these, because this isn't a physical Web talk. In the future, we're going to integrate the physical Web with Web Bluetooth with a feature called Referring Device. So if you go to a physical Web Beacon's URL, this actually gets exposed when we load the page that it came from a specific Bluetooth device. And when you know that, this exposes the GAT server, the Bluetooth device directly. So if you walk up to a parking meter, you don't have to figure out then which actual parking meter am I at, because it just went to a URL. You can actually make sure of that because you're connecting directly to the device. So Web Bluetooth requires you to flip on an experimental flag in Chrome today. It also works on Chrome OS, Chrome for Android Marshmallow, Chrome for Linux. We're diligently working on the OS 10 and Windows implementations. If you're on Lollipop, you can still use it, but you have to use a Chromium build. And it's also implemented in Opera. So to get started, if you're interested, by the way, just Google Web Bluetooth samples. It's really the easiest thing. Like I said, we've got a code lab that we're running tomorrow and a bunch of devices to play around with. We also have a pile of physical web beacons that you can keep. We don't have enough for everyone, I don't think. So we'll figure out how to throw them at people was my idea, but they said no. With that, I hope this gives you an idea of some of the exciting areas that are going to make progressive web apps even more exciting in the future. So if you're interested, please come back tomorrow. We've got lots more talks from other browser vendors, partners, and you have a chance to talk with us in office hours and experiment in the code labs. So thank you very much. And I think Paul Kinlan is going to come back up and close things out.