 You've probably tried to buy something online or had to fill out some form for your kid's school and it's really hard on your phone. It's really hard. There seems to be a dark art when it comes to native applications, and they're such small details that you're actually working on. Quite often developers will just throw an input fields onto a page and not really think about the UX that's attributed to that. So they'll think of a flow of a form, but they won't necessarily feel about individual inputs or how a user struggles. We know that auto-complete really helps speed up the user experience and makes filling forms quite nice. What are your feelings and experiences on auto-complete and auto-fill as a thing? I mean, from the user experience, you've probably tried to buy something online or had to fill out some form for your kid's school and it's really hard on your phone. It's really hard. I mean, it's even hard on desktop. You don't want to get up and get your credit card at your purse, which is downstairs. These browser features just really improve the user experience of using a form. In fact, we find that people submit the form 30% faster if the form works with auto-fill. So we very much suggest that developers think about this. You want people to be submitting your forms, right? So if you really want your forms to be submitted quickly, easily, work with auto-fill. Why do you think developers don't do that? I mean, is it very difficult to do? Because I mean, I'm assuming it's just a few attributes you add to inputs, right? Yeah, it's actually not that hard. So you basically need to set up auto-complete attributes and you need to make sure that you're not doing any fancy things that replace the normal select and input elements with other types of elements. I think most of these developers just don't think about it, don't realize that you just need to put a little bit of extra effort in to make sure that your form works well with auto-fill and to test it out. I mean, is that one of the challenges, I suppose, like people making these custom UI things which are not native, but just like divs or whatever and replacing that? Is that where things fall down with auto-fill? Honestly, there's a few things that can go wrong, but that's one of the big ones. Yes, you know, someone wants this really beautiful custom form where the drop down is all fancy and custom. And as a result of that, they're using all divs and the browser can't figure out, oh, this is supposed to be a form. And then in that case, auto-fill isn't going to work. And I suppose there's like a lot of accessibility issues connected that well, it's like. But from your point of view, you've got like designers and developers, they want to do something custom, like unique experience. But then as someone who works on the browser, you want to say, now, let the browser do the work. I mean, do you think there is like a middle point there? I mean, how can developers like at least have a custom experience that's unique to their product, but at the same time without breaking standards? I mean, because this is one of the biggest challenges on the web. So, I mean, there's a lot of things you can do to change the look of the form on the page while still using the select and input elements that HTML provides. You can customize them in many ways. I have to admit, there is one thing you can't customize, and it's the look of the dropdown like in a select element, right? But everything else, the way it statically looks on a page, you can customize and the browser will still know that there are fields. Yeah, I mean, what do you see is the biggest challenge then for auto-fill or like implementation from your point of view? I mean, I think it's honestly that developers don't think about it, you know, that people don't think to themselves that they really need to be testing their forms in this way. You know, when you've made it yourself, you filled it out 100 times, you tested it yourself, and you don't think about the fact that a user is going to be coming to it in a different state of mind, right? They're tired, they are trying to fill out as fast as they can on the phone, right? So, I think developers just aren't really thinking about the fact that they need to take these extra small steps. So, in terms of like browser compatibility, I mean, the things you're using will be Chrome-specific stuff or is that like open-source, like not open-source, but it's cross-platform? Yeah, that's a good question. So, specifically, autocomplete attributes for auto-fill, that's standardized. Different, all the browsers respect them. With that being said, there is one part, turning auto-fill off, that's the autocomplete-off attribute, is not respected by all browsers. But if you say this form should be a credit card, that'll be respected by all the major browsers. But each experience, is there like like works per browser? Because obviously that's going to be a browser-specific thing. I mean, some are, you know, they have very slightly different UIs. For example, maybe they'll be integrated with the keyboard widget versus a dropdown. But I think they're pretty similar across browsers. You work on the actual Chrome UI itself. Yes. So, are you actually building that design encode yourself or are you working with UX designers in that process? So, we have a design team, and the design team helps us figure out what those UI elements should look like. We actually have a big redesign coming up this year that I think is going to make those substantially more beautiful and also help clean up the code, which I know that won't affect most people because they won't look any different, but from our perspective. It's much cleaner. Yeah, and the code's so much cleaner. I mean, how, what's the actual process of you actually creating UI? Because for me, it's like, I do front-end development and code, but it's like, there seems to be a dark art when it comes to like native applications. It's like, and there's such small details that you're actually working on, which the user may not notice because it works, but if it's broken, they will see it. I mean, what is the actual process that you go through with like your Chrome designers to actually making DUI or testing it? I'm asking lots of questions. Yeah, it's okay. So, I'll talk about the process a little bit. So, usually at the beginning, product, end, and the designer will get together and sort of talk about what they hope for from the future. Often, the designer will then come up with some conceptual mocks of what they feel the feature could look like. We'll get feedback from product, we'll get feedback from the engineers, like, can we actually build this? What are the corner cases we need? And then we'll sort of iteratively get closer to what we actually can ship. So, I work on a cross-platform team, which means that what we build has to ship on all of Chrome's platforms. People think of Chrome as one platform, but actually, it's Windows and Mac, which previously had different UIs, but we're coming to one single standard, Android, iOS. And so, we have to have different mocks that relate to the specific platforms. So, some things may be possible for some subset of the... Anyway, the designers get all this feedback from engineers, like, we can do this here or not there. And then we iteratively come through to RedLines, which is our final set of designs, and that's what we implement. So, I mean, in terms of like, do the designers work with the actual W3C? Because you're designing something which has to be considered cross-platform at the same time. So, when the payment request API, like, I was working with some of the team there, it's like, there seems to be things where you have to really be seeing what everyone else is doing so that the experience that you're creating is not so widely different. And that can be quite challenging for the design developer because you're instinctively want to make it, I don't know, better, but you don't want to make it so vastly different because then you stick out. That's an interesting question. A challenge here is that with specs, we try not to specify what the UI has to look like. We try to talk about what the user experience should be so that we can have the appropriate callbacks, et cetera, to build that experience. But we don't like to standardize the UI itself, which is a fine balance because you have to have a UI in mind when you're designing the API. But we try to make it as general as possible so that we can build different UI experiences on top of it. Are you working with the browsers as well at the same time to do that? Or is it you do things independently, because there's a thing of like, if you do it over the browser, then you may be led down a path that's not the best for everyone, but it's okay, it's like a compromise. But at the same time, you don't want that complete disparity. It depends a lot on the standard. Honestly, some of them will be heavily driven by Chrome or some other browser, like they really want this API, they'll drive it and then get a little bit of feedback along the way from other vendors, whereas others from the beginning there's several different browser vendors working together. So honestly, it differs from standard to standard. And we're coming to like the 10 year anniversary of Chrome. What do you think the future of, say, Autofill or just like working with the other browsers? Because it seems like things are getting much better. Like I was speaking to Darren and then say, it's like the implementation of Flexbox was a nightmare because their standard kept changing, but with CSS Grid, it's amazing that there's so much cross collaboration between the browsers, which is great for the end users and the developers working across this. What do you think the future is for Chrome as a platform and I suppose Autofill as well as a specific? So for Autofill specifically, it's hard to say because I don't think the limitation there really is the lack of browser vendors cooperating. I feel like actually, there's been a lot of discussion for example, around payment requests was a lot of collaboration between Safari and Chrome. I think that the real problem we have is that Autofill depends on developer adoption, right? If it's hard for the browser to figure out what forms in the page, we're not gonna be able to Autofill it, right? And so I think the thing we really care about is whether we can developers interested in and using the tools that we've provided for them to try to improve the Autofill experience. Yeah, I mean, do you ever have to remove a feature when you see there's not wide adoption? Because I mean, I can see from an engineering who's working on Chrome, you spent your heart and soul working on this feature and then you know it's great for user experience. You know from the research that people like, Autofill will help transactions and it's just nicer. But if the adoption doesn't happen, I mean, that must be, how do you get? I mean, it's the biggest. Yeah, that's a really hard one. I've been through a few deprecations. They can be really challenging. It's very hard. So there are a few ways you can look at it. One is how many users interact with websites that are using such a feature. And obviously that number is large. You don't want to create a pain point for a lot of users, but even if that number is very small, it might be that there are a few websites, a few companies whose entire business model depends on having access to this API. And so that can make it very difficult where, okay, even if it's this really niche thing, it still can be hard to deprecate. So I think there have been lots of ongoing discussions in general about how to make that trade off. So one of the ones I've been involved in really specifically to security and TLS, where if something is making the web as a whole less safe, we may have to break some connections in order to deprecate it. And it can be a really painful thing when you've got old servers on the internet that aren't being upgraded and maybe it's only a small percentage of overall page loads, but it's still frustrating when a user is trying to get to a website and it's broken. Yeah, but I mean, ultimately from Chrome's perspective, it's the user's experience that's paramount, right? And their safety and security. So it's like HTTPS. I think there was, you could probably explain it better, but there's like a cutoff point where if your site is not loaded on HTTPS, you're going to get like a message saying, this isn't secure. Is that that's true, right? For a long time in Chrome, we showed HTTP is neutral. HTTP is just plain text and no TLS. So what's TLS just for my non-designer? Oh, TLS is, so the underlying protocol that makes HTTPS HTTPS is Y secure. So there is HTTP, which doesn't have any of the end-to-end security bits on it. And HTTP websites, we're just showing it's like a neutral standard thing, right? Most websites on the web are HTTP, but that's changed. We went from a few years ago, we were at 25% HTTPS and now it's the opposite. We're at more like 75% HTTPS. So we've made changes in the UI to back that up. So now when you go to a website that says HTTP, it's going to also say not secure next to it. So people don't really understand what that means. Is that, I mean, that decision must be quite tough, though, it's like, in some respects, you need to force the developers to say, like, use as secure as paramount. But at the same time, does it feel like you're breaking the web? It doesn't really feel like we're breaking the web. First of all, I think people have seen this long time come. We've been talking about it for a long time. We've rolled it out in phases. So first, we started showing not secure specifically for pages with passwords and credit card form fields. And then it was for all form fields and web pages when viewed in Incognito. And now we're rolling it out for all HTTP websites. And as you can see, you know, because HTTPS adoption has really increased, it's only impacting less than a quarter of page loads at this point. So really we're just talking about protecting the user. Yeah, and I think users have a right to know that their information isn't secure when they're going to this website and that help them make a decision about whether or not they want to keep using that service or go to another one. And do you think users are quite savvy now to, like, see those things? Or is this part of the education for the user as well to say, look, there are certain things on the web which are not secure that you have to take into consideration? I'll be honest. We have literally billions of active users. So it's hard to say generally whether people are going to understand it or not. We think enough people understand it that they have a reaction and that they can reach out to sites saying, hey, I really like this site, but I wish it were secure. And we see people doing that as we've been rolling out these warnings. The way that cellular networks are set up is that there's always these, like, fringe areas. And there's always these breakdowns. And just higher latency is always there.