 Oh, it's Alex. Oh, hello Alex. This one's Alex Russell. My first guest, Alex Russell. You keep going. And we have Jacob Rossi from Microsoft. We have Harold Kirschner from, are you coming the rewarder? From Mozilla. Andreas Bobins from Opera. Keep going. Keep walking. Oslo. Maslow Gombosh from Samsung. Hello. And Alex Russell, I've already done. Tal, Oppenheimer. There we go. Well, this was well rehearsed, wasn't it? Is it, do I go away now? No, yeah. Yeah, don't keep me around. Big round of applause for the panel though. Now you know that nightmare feeling where somebody invites you to like a fancy dress party and then hours before they let everybody know that it's no longer a fancy dress party and yet you show up in your fancy dress. I don't feel like an idiot, not one bit. Now the other thing that has occurred to me is that live questions are actually quite a lot of fun. And I thought, well, I have mugs and they could act as an incentive. So there are microphones there and I think maybe over there. So if you have a question for our panel, please do feel free to avail yourself of the microphone and afterwards you get to come and pick up a big web quiz mug. That is exciting. Okay, we'll get on with our first question then. Let me see. So everyone's heard a bunch from Google about what Chrome's priorities are for 2017 for the other vendors. What are your 2017 priorities, please? So I guess we could start with Microsoft Jacob. Do you want to go for it? I hate to say it, but actually it's progressive web apps. Patrick talked a little bit about this earlier, but we're in the process of building service worker and push and all these things. And I think we might be one of the first to try and bring a full PWA experience to a desktop. That gives some weird challenges that we're trying to figure out. But yeah, can you elaborate on what some of those weird challenges might be? So if you think about adding a PWA to your home screen on a mobile device, like you can hit the button and the browser Chrome can kind of fade out and now you're in the school full screen app experience. What happens in a windowed browser? Does it lift up out of the tab? Does it magically become super powers? So there's weird things like that that we have to figure out. There's also things like how do you transition from if you have it installed, but go to the browser and type in the URL. What do we do? Do we keep in the browser? Do we jump you back out to the app? There's things like that in a windowed environment that are a little different that are a little bit more gnarly. Cool. What else have we got? Oh, a Mozilla in the house. Yeah, I think the general theme here was performance. So that's also something for us to focus on. So probably saw the announcement for Project Quantum, which is we're trying to get pieces from Serbo to paralyze things on the web and also make better use of the GPU. And that will bring the web forward with service workers and web push. We can provide them the greatest experience and animate even more things. So that's the part at least for the user experience on just on a platform level. That on browser level, working on web payments and other services that were also mentioned here, they're just crucial really to really get from end to end for user, like the lift experience of one of the payments I want to be able to sign in. Those are definitely the focuses. So that's you seem to look out for from a PWA side. We're looking at the home screen for Fennec, for the Firefox on Android version. There's this kind of where there's a beaten path. There's definitely room to explore other ways. Like how do you get people to add to the home screen? Things are clear like for many users. There's big benefits we saw in numbers from performance. But what are the benefits for users from adding to home screen other than the three apps where you spend 80% of your time? It's some room to see how users understand apps and how they want to reengage with them. Especially if we see also stories here how first users come to the web and then buy something just because it's really easy on a web. So what's the return value? It's interesting to hear you talk about the web payments. Just coming back to you, Jacob. What's the status with Microsoft and web payments? Yeah, we have a prototype of this. It's under flags in Edge today. We're in the standards group working on this. We're excited about making the web on an equal playing field with native apps in terms of just buying lots of stuff. I do it. It seems like a good thing for everybody. Good. Okay. Andreas. Hi. Well, we have been working on implementing progressive web apps over the last year and a half or so. I think we have an implementation that's pretty much on par with the implementation of Chrome on mobile. There's one thing missing which is background sync, but it's coming real soon as in next week or the week thereafter. So that's nice. In 2017, some of the things we want to bring to the browser is web Bluetooth as well as web payments is also coming. We also still want to experiment a bit further with how to bring the user back from a progressive web app into the browser, sort of break out of the install progressive web app in full screen or in standalone mode and bring the user back to the browser. We did some early experiments with that earlier this year, but we, you know, it was sort of an initial idea. We have to further fine-tune that a little bit and sort of see how, you know, which kind of flow makes sense. Also, general web app discoverability, should there be an icon in the address bar that, you know, indicates that a website can be installed as a web app and things like that. So there's a lot of UX research and things we have to figure out there. One more area is permissions. Should they be, you know, how upfront should you be? Should they be, you know, model? Should they be a slide up? What is a good, you know, way of interaction there and UX pattern? So those are the things we are exploring and sort of trying to, yeah, make it an overall better experience. Okay. And Laszlo. So I have to start with progressive web apps as well, just to make sure that the core experience is there, service worker, web push, so on and so forth. We've been also part of the Chromium ecosystem, so implementation is generally on par with Chrome and Opera. In addition, I want to emphasize web payment as well. We have a lot of learning in that area coming out from more Samsung Pay initiative. So you want to bring that learning into the web and add it to the Samsung browser as well. In addition, we're focusing on virtual reality. That is something we've been involved with for over a year now. We have a VR-only browser that basically only works in VR, and it's a separate download. And so we have a lot of learning in that space as well, around 360 videos and web VR and so on and so forth. So that's a priority for us for next year as well. Okay. So mostly it sounds like progressive web apps from everybody, web payments, and then a smattering of VR on top for Samsung. We have a live question after which, fail yourself of a mug, won't you? Go for it. Perfect. Thanks. Also, you look really good in that tux. Thank you. But you voted for me to wear it, didn't you? Yeah, I did. Thanks for nothing. Your question? So my question is about HTML imports. I know it's kind of a touchy thing, and I know there's a lot of opinions about what we want and what we want, what would be a great thing, but I mean, what's the harm in just implementing it? I get the sense that some of the audience would really like to see HTML imports. Who would like to go first? Can we go with... Yep, go. Yeah, happy to go first. I think that's... So we put it on hold until the modules land, and it's not that we declined, basically, the spec. It's just like... It might have looked from the blog post if you read it that way, but... I think I read it that way. Yeah. It seemed like it was like a fan film, no. Maybe, maybe, maybe. Okay, okay. But so basically, we were waiting for how will people use the next module for us. Firefox, as in the work, doesn't have thousands of engineers, so there's always a question of priorities and how far it specs along, and are the concerns addressed? It's just a standard process, basically. Yeah, I've heard that answer a lot before, but it looks like it should be pretty simple to implement anyway. I mean, it works in Chrome, and it's like... It would be really helpful for a lot of frameworks and a lot of web components, really. I think the scenario is completely valid. I think you heard it even from the Google folks yesterday, right, that what we land on, I think it was Dimitri that said this, it's going to... We're going to have to solve this problem, but it's probably not going to be as dual-imported as it is today, which as a browser vendor is like red flag, like, you know, I don't know how many of you like to go code something that doesn't end up making it to your customers, right? So, I mean, you have to think about how these pieces cohesively fit together and modules and whatnot, and that's part of our job as, you know, sort of standards conciliators, is figuring out how they all work together. Happy? Got it. All right, go and get him. That's all you did. That's what you wanted it for. There is an elephant in the questions that I want to address very quickly. Should start by saying that we actually did invite Apple to join us on stage, but they declined. We are glad that they're here at CDS, and I'm pretty sure I speak for everybody when I say that we would like it if they could be available for these kind of panels. And the question is, how does collaboration with Apple actually work? They're generally not present at these kinds of events. So, I was wondering how that translates into the TC39 slash standards process, which, I mean, Alex, you've got a lot of experience at TC39. So, I obviously can't speak for anyone at Apple, right? I can only give you the perspective that we've got on the Blink team and from the standards team on the Chrome team. And what I can say is that Apple has some of the strongest engineers that we've ever worked with from any browser. No offense. Apple employs some extraordinary people who really do want all the right things for the web. And there's no sugarcoating that. There's no asterisk. There's no question mark next to that. That's absolutely true. And we are grateful every chance we get to work with them. Now, we all work for companies, and those companies have needs, and those companies have priorities. And so it would be amazing if we got more opportunities to work with them, and we'd like that. So the answer is, it's great when we get to. So, could we get more of it? We'd love that. Perfect. Just because it keeps cropping up, and I thought, we should handle that one. Right, in which actually somebody's like Apple and Service Worker. When? And I'm thinking somebody from Apple would be the right person to answer that. So I'm not sure we really can. Good. An in-person question. I think you were there first. No? That's very decent of you. You could have just been like, whatever. Yeah, I was here first. Over this way, then. You're quite, hey. So last week, Mozilla announced the Fly Web API to launch a web server from a page, and Google has the physical web. So I wanted to ask, are you guys talking? What are the other vendors' plans about Internet of Things regarding these recent APIs? Okay. Regarding Internet of Things. So Fly Web is a different approach. So the end of the things is everybody tries to put URLs right now somewhere. It's a very simple approach. Just put an URL on the spot. The Fly Web approach is the way you could do it offline. Like, your light bulb could provide you a service. You just open a page. So it's kind of the micro network of, like, I just log into my light bulb, and I kind of just use it. So it's basically working against, like, I have to install an app for everything, and I have to be online for everything I want to control, and it has to be a server that I communicate with, and then talks back to my device. So it's taking it to a more local level, and giving these powers that the web has that they just have a link to some local service into, like, this thing that you can then connect to. It probably doesn't scale to all devices. Like, they're still micro-port devices that just want to, like, upload the data to your router and then go to the cloud, but there's probably a set of just in a museum you walk around and you can connect to different things. So there's a ton of use cases where it's really interesting. Yeah, at Opera, we implemented a while back. We released a labs build with Beacons support, so you could look and list Beacons around you. Back then, we also thought it was a good idea to sort of show you, I believe, to look at your geolocation and show you Wikipedia entries around you as in, you know, objects or buildings around you and so on. So sort of mix up sort of virtual Beacons, if you will, basically geolocation coordinates and real world Beacons, and to sort of see how that would work. We learned a lot from that labs build, and we'll be further fine-tuning and rethinking a little bit how we want to how we want to move forward with it. In our case, the new Opera we've been building for Android has sort of more a card-based approach with news items and so on. If you download the Opera beta, you can see that. And so, if anything, we'll probably look further at can we do something with these cards to show you Beacons for around you and so on and so on. So it's definitely still an area of interest. And then, of course, also web Bluetooth, as was already mentioned, which is also, you know, strongly related to Internet of Things is also still a focus. So, yeah. And within Mozilla, we also have a connected devices team, which has a project which also looks at how can we show Beacons to the user to discover. So we attack it from both sides. So one is actually in platform, the other one is in connected devices, but they're having different approaches on how to do this. That's the kind of stuff. And Flyweb is definitely the newer approach, like a very different angle on no problem. And I'm really excited that it's now out, so it would be great what people do. For us, we have, there's a version of Windows 10 variety as well that it enables what we call hosted web apps, which you can kind of think of as a precursor to post it, progressive web apps. It's without service worker and that type of thing, but it's running on the machine. It pulled from a server. You can access it running on like a Raspberry Pi or something like this. So I wouldn't say Internet of Things is my personal area of expertise. These all sound like proprietary or sort of separate sort of ventures into this area. Are these kind of coordinated and I don't know about it, or are these sort of individual kind of vendor things that one may survive or whatever? So for our design, it's the same edge HTML engine that runs inside of the edge browser. So the same standard support, et cetera. Today it's hosted web apps. Tomorrow it would likely be progressive web apps as well. So we're not in that realm. There's nothing really here that's proprietary isolated. It's all based on the standards we're developing for all devices. Good stuff. All right. There's a question here, which I think is actually pretty good for everybody, which is, yeah, good. Enjoy it. What are browsers doing to combat intrusive adverts on the web which ruin the web experience for everyone? In the middle of reading an article, mid-page load and suddenly full screen ad, or suddenly an ad starts playing video or audio and it just makes me wish I'd use the native app. Ouch. And I guess that's aimed at mobile browsers, but generally speaking. Well, obviously we've mentioned, Google's mentioned things like interventions and actually starting to kind of push back on some of these things that users find horrible. What is everybody else doing? I think a big part of it starts with talking with ad reducers and one of the features that a bunch of us are working on, including Edge, is intersection observer in terms of giving them the right tools to be able to get out of the way and meet their needs, because they're very real, just like yours, and helping them build their business model without impacting your user experience. And I think that intersection observer is a great example of one of the tools we're giving them. Okay. But your take on this is go to the ad networks first rather than a stronger pushback? Well, I think it's important, there are customers like anybody else, and I think some people make their business thrives off of ads, and some people do. I'm looking at a few people, but no. But they have real scenarios, they have real needs, and they're web developers also. And I think instead of just simply hitting them with a band hammer, we can try and help them build what they need in a more user-friendly way. I do think there are places where things like interventions play an important role in helping be paternalistic and pushing them forward with the rest of us. Anybody else? Yeah, in Opera, we have a data savings mode, and that it only compresses HTTP traffic, so it doesn't touch HTTPS traffic. But if you're on HTTP sites, you can, or for HTTP sites, you can check a box that blocks ads, maybe a bit controversial, I don't know. But we see users taking that box and actually getting a faster browsing experience like that. But as I said, it only works on HTTP sites. So for HTTPS, that wouldn't have any impact. But that said, I don't think it's sort of more of a hack or of something, you know, putting some power in the user's hands when they're very concerned about data savings and they don't want to waste just bandwidth on. They can also turn off images. Opera's not against images, but it's just, you know, so Opera's also not against ads. But it's sort of more a tool that users can use to get a better web experience. They can also compress videos and things like that. But that said, I think it's the whole ad or sort of intrusive ad problem. Overall, it's something that can only be solved by talking with ad networks. And that's one of the things we've been doing to sort of see what can be done to make it less intrusive and also probably tweak some of the APIs. So just, for instance, the vibration API, it's now available. I've noticed sometimes I was on, well, you see on websites, some websites that have some really crazy intrusive advertising that make your phone vibrate. I was on mirror.co.uk and suddenly I got a vibration ad in the background somewhere. So those kind of things shouldn't happen, actually. So there it's a matter of, you know, is, for instance, a vibration API should be possible that just any site that you've never visited starts using this or should there be a prompt first for the user to, you know, things like this. So there's different things that we can design to make those kind of terrible ads at least disappear. So it's a bit like pop-up blocking, for instance, that also browsers to care of. And then, yeah. Yeah. So in Samsung, in an advisor, we have also a model where on client side we allow blocking certain content requests. We call this a content blocker extension. And this is something where we feel that there's an overwhelming demand for a feature like this, but we don't necessarily think this is the solution. I think this is just part of the conversation on how to actually proceed. And one of the interesting aspect of our solution is that it doesn't actually leak browsing history back to the extension. So that is something that the engine sort of self-constrained and executes these rules. And another interesting use that we've seen of this feature is that people actually, some of the people actually more concerned about the tracking and privacy aspects of ad blocking and not so much about the ads themselves. So we have a few extensions that specifically targeting blocking tracking. Yeah. I think that shows how the multi-fold style of the problem, like you mentioned, like this is forward screen out, which is a UX problem. Then there's a data problem. There's a privacy problem. I think we're mostly like, we have a test pilot open for the tracking protection, which basically just blocks trackers that don't obey to do not track. So that's the one angle, like you just want to have private secure browsing session. And the other angle is just, I think, talking to ad networks and letting them say, like, here, new APIs, you don't have to hook on, it's a scroll and make everything slow. And there might be other things like payments API, like making the ecosystem healthier that websites can actually have better ways to engage with users and ask users, like, do you want to pay for this content? Or, yes, like this. And we talked to a lot of publishers on the web, and some have control over that network. Sometimes it's in-house, and they can actually talk to people. Sometimes they're just basically bound to the ad bidding process. And you get 40 redirects before you get the ad. So it's just a whole radius right now. And I think the ad industry, like, they're moving forward. They're definitely don't serve the user in the first place in some cases. But I think there's definitely feedback for that has to be solved. Okay. I'm mindful of time. And so, and I know you've been stood up for ages. I'm so sorry. You could have taken that spot earlier. It would have been great for you. Sorry. Go for it. Okay, I'm lost. In Denmark, we have a saying, something like, don't throw away dirty water before you have some clean to replace it. But that's more or less exactly what you Chrome guys did with the removal of apps on the non-Chromo S devices. So in our case, particularly hardware connection, we have a problem with that. So I was thinking in a positive note, are the different browser vendors actively working together on getting some of those more useful features into web extensions rather sooner than later? Because right now, I'm sure it's not only us where the carpet was just pulled. So anything on that? I can say, sorry, I can say from the Chrome side that we're actively working on a bunch of APIs to help connect you better to hardware. So I think it was last year, we launched Web MIDI to connect you better to MIDI devices. We've launched Web USB and Web Bluetooth as origin trials, which are sort of experimental APIs you can try out if you register for a key. And those will connect you to a lot of the available hardware. It's not everything. It's not a serial port. I get it. And it's not all of Bluetooth. It's just the Gap profile. So there are some aspects about this. So we're trying to work in the standards process to design APIs that address most of the needs that we hear about frequently. That does leave a long tail, and that long tail is difficult to deal with. And so we are actively looking at ways of maybe addressing it. There's a new generic sensors API, for instance, that's a proposal out of Intel. We're interested in seeing where that goes. So those are the sorts of approaches that are coming. But I feel your pain. I'm sorry. Yeah. Just follow up quickly on that. The thing is that, as I say, Web USB and many other things are focusing a lot, if I can be frank, on like hipster technology companies, not so much legacy big industry potential partners who have a lot of hardware out there. You can't just change. Many of them use off the shelf chips that you can't reprogram on all this. I mean, they're left behind where you have a huge opportunity in enabling those guys, which worked with the Chrome apps. Okay. 24 time. Okay. Well, we will, I think it's probably worth having a conversation afterwards and go on. Okay. We will move on. We heard a lot about development in emerging markets in the keynote and in AXIS talk. What is the most important thing to do to try and break into those markets? Probably. So in general, my usual answer to that question is build a progressive web app. Given this particular audience, that's probably too vague. But one of the things we do see in general is progressive web apps, especially compared to native, are a lot easier to get the user to actually interact with your experience in the first place. And when native app developers are facing entering these markets, they're realizing that people might find their experience, but they don't have their room on their phone to actually download it. They don't have the data or the connectivity to download it. And even if they get it on their phone, you have the same problems to actually get it up to date. So it's sort of a one time bet. And all those sort of move away with progressive web apps. But for those of you that are hopefully already invested or thinking about progressive web apps, I think the biggest takeaway is actually quite similar to what we think when we think globally, which is performance. It just means a very different thing in a lot of these markets. It means different networks. It means most of the users are probably going to be connecting to your experience on a 2G network. They'll be losing connectivity much more frequently and unpredictably. So it's not that they went into airplane mode because they got on a plane, it's that they just lost connection right now. And in line with that, they will sometimes go into airplane mode because they don't want to spend data. And so it's really the performance that you're thinking about has to take a bit of a different angle. But I do think that the key takeaway as you're thinking about progressive web apps experiences for these markets is around performance. At Opera as well, we have a lot of our user base in emerging markets. So for us it's also very exciting to see the potential of progressive web apps in those markets. I had a pleasure to join some people from Google on the Progressive Web Apps Roadshow in Sub-Saharan Africa. And so it was really interesting for me to interact with local developers. And I really urge you, if you haven't talked to the folks building Conga, for instance, to go and talk with them because they give a very interesting insight into why progressive web apps matter and how they can make a difference. One of the things, there's connectivity, of course, and service worker and so on, was background sync. And it plays an important role. Also the small size of initial download, not that you have to start with a 20 meg download of a native app, of course, makes a big difference. And also device storage. A lot of people run on underpowered phones, they run out of space much faster, maybe then if you have the latest and greatest Western market phones, so to speak. And so progressive web apps fill that niche really nicely. So they solve this problem by not taking up so much space on the device and generally being much lighter. So this is very exciting. I would also add that web fonts talking about performance. It's a fascinating thing. If you chat to Monica, she was recently away and was stuck on a 2G connection and then became like a one person sort of war machine against web fonts. She was like, they're the worst thing ever. And I'm thinking if you go into an emerging market and you're like blocking on web fonts, then they might not be that appreciative of that fact. It was just a minor thing that occurred to me on the way through that when you're talking about performance. We probably can just sneak one final question in if it's a quick one. Are you there first, right? Yeah. Yeah. Yeah. I'm not missing this one. All right. Let's make this a quick one. Go for it. So this question is about the progressive performance itself, why I think it's not really true. One of the problems is like, you know, most of the time in emerging markets, there are a lot of phones that are not really that good. And because they have these older browsers, you end up with polyfills and shims and you end up actually downloading more libraries. And so there is this chicken and egg problem where, you know, developers like us who built for emerging markets wait for the features available in all the browsers. So I mean, the point is if we wait too long and if you're looking for data that the developers adoption are there, I don't think that's going to happen. So even if it is minimal feature and it's available across the browser, I think that should take priority rather than moving fast and fail fast to find out developed production for these kind of progressive features. Does that make sense? It feels like progressive enhancement is part of that story there. If the planning requires lots of polyfills and libraries and shims and so on in order to get going, this comes back to what Alex was saying about using the platform and maybe just considering the user experience. I shouldn't really be answering these questions about necessarily all the same. It just feels like there's a fundamental question there about what experience is trying to be delivered. And I totally hear that some of the things you can't necessarily polyfill and share my service workers. But it feels like if there's other things that are standing in the way, like you're downloading large frameworks and libraries and so on before you go there, then the platform, you should be maybe thinking about that first. Anyone else? I think there's a trend now going backwards to building on the server side, the package for the phone, like that just works for that phone. So I think that's just because we want to minimize the network used to just the server knows hopefully enough about the phone to make a good decision on what he needs to serve. So because from a hands man kind of kills the whole web idea by adding like all these polyfills and you want to make it this way, it's not going to fall back to the other way. That doesn't work like fall back to the other way. So I think that there might be just a trend like if you get a low in phone, serve them the low in package. So just cut down on the CSS and fidelity and just make it work. I think also if you kind of marry Alex's talk yesterday with Patrick's talk earlier, like you have to think of new approaches. Start from a clean slate and maybe a lot of these polyfills and frameworks that were developed in a world where desktop was primary from years ago, especially if you consider the year that these browsers you're talking about came out and the state of the art of polyfills then was very much a desktop world. And they were also meant to be full fidelity polyfills in a lot of cases. They're trying to be spec compliant and prove that you could have full backwards compatibility, but maybe your scenario doesn't require it. And so going and looking through the grab bag of older features that might be available on those platforms and just looking at the pieces of the platform that you need, maybe a strategy that helps. I think those two strategies married together kind of are a good way to go. Well, we are all out of time. Don't go until you've got a mug. I'm not taking these back to the United Kingdom with me. I mean they're highly prized. We are all out of time. Please give our panel a warm thank you.