 I'm working for Samsung as an ambassador for the Samsung Internet Project, and you may have also heard my name because I am co-chair of something in the W3C called the Technical Architecture Group, or the TAG. It's a group that Alex Russell also sits on, and it's kind of a steering committee for web standardization, particularly around W3C stuff. I've also been working on the web since before there was a web, so like Alex, I also remember when you had to yell, don't pick up the phone, and I've also been working to bring the web to mobile for quite some time, so I'm going to talk about some of the work that I did originally on something called the mobile web initiative, which is from a kind of earlier era of the mobile web. But I think it's important to realize that mobile devices have been around on the web for a while, and we're really now coming into a new phase, I think. Jun Ki here, who's going to talk for most of the presentation, is a core member of the Samsung Internet Engineering team, and he is also co-editor of the Service Worker specification, so he's been working within the Progressive Web Apps sphere for quite a while as well. So anyway, if you've been paying attention to yesterday's presentations, you may have noticed something. When people listed out browsers, along with other great browsers out there, there was also something else, something that you might not have recognized, right? Okay, so, yeah. So, right, so, yeah, I knew about these other things, but really, I knew about these other things, but what about, what is this? What is Samsung Internet? What's this doing here? What's this new logo that I don't recognize, right? So we're going to answer those questions today, and so I want to tell you about, we're going to tell you a little bit about what Samsung Internet is and why it's there, and the work that we're doing on it, and why we're pretty excited about it. Although, since I am applying for UK citizenship right now, I am legally prohibited from using the word awesome, so I can't say that about it. But it is really great. So we're going to talk about that, and we're going to talk about Progressive Web Apps, and in particular, Service Worker. And I'm going to have a brief break for some philosophy, and then I'm going to talk about something else at the very end that's quite interesting to us, and is of particular interest to Samsung, which is web and VR, and some work that we're doing to bring web and VR together that you might not have heard of. And throughout this, we're going to be re-emphasizing something here, which is our commitment to standards, and in particular, our commitment to implementation of web standards, and our work that we've been doing in order to promote web standards, and to develop those web standards, and to really make sure that we have a web that's based on standards. So first of all, I want to talk a little bit about Samsung Internet. What is Samsung Internet? So our articulation of it is that it's the latest web tech in an easy-to-use package, right? So it's the default browser on Samsung phones, in particular, Samsung Galaxy smartphones and tablets. It's based on a Chromium project, open source, obviously. But what you might not be aware of is that Samsung is also a major contributor and committer into Chromium. So we're actually, we've actually got a lot of engineers based in Seoul, based in Boston, that are not only working with the Chromium project, but also working very much as a part of the Chromium project. And as a separate project that we have, which is a GearVR browser, this is our VR specific browser. It's based on the same core, and I'm going to talk about that in a little bit. So why should you care about Samsung browser? Why should you care about any of this? I wanted to display a graph, which I think articulates why you should care. So in Europe, according to stat counter data, Samsung Internet is actually the number three browser only behind, well, Chrome and Safari. This is for all mobile browsing. So this is actually a pretty significant number, and the number in North America is pretty similar. So once stat counter actually started breaking out Samsung Internet from the relevant Chrome version, it became quite clear that we actually had a pretty sizable market share. In fact, beating out the previous kind of Android browser, which includes, which is the kind of legacy device browser. The other thing that I wanted to mention is why is that? Why is that? Because when people get their new smartphone, when regular people kind of get their new Samsung phone, they turn it on and they see a button that says Internet, and they're like, I want to use the Internet. OK, they hit that, and they start using the web. And we want to make sure that that experience is up to date and as good as it can be. They can get the best possible web experience, including support for progressive web apps. We want to make sure that that's in place. So some other features of Samsung Internet that kind of differentiate it. First of all, we've got password keeping, which integrates with the fingerprint sensor. So that's kind of in line with integrating into the device capabilities. We've got to focus right now on protecting users' privacy or privacy. And that's partly why we've implemented a secret mode, which is like the incognito mode or privacy mode. But also, we have a content blocking extension API in Samsung Internet, which is quite innovative, I think. And I'm going to talk about that in a second. There's enhanced multimedia experience and mobile to VR continuous experience. I'm going to talk about that in a second. We've also got custom tab support. And if you want to read more developer resources about Samsung Internet and what differentiates it, this is the URL to go to. So importantly, Samsung Internet also supports not only the latest and greatest Samsung devices, but it's also backported to a whole bunch of previous generation devices. That's something new for Samsung. Another thing that is new is that updates are not linked to firmware releases. So now we have automatic updates that are rolling out through the Google Play Store. And that is best practice. And that's something that kind of changed with the release of 4.0 browser earlier this year, which also included progressive web app support and push notifications. So I just want to cover content blocking API. This is a third-party API that basically allows third parties to build content blockers. So we have Adblock Fast and Crystal, which are already in the Play Store. And you can download those and install them separately. We developed this because there's a strong user demand for content blocking applications like this. It's quite controversial. But again, I think part of the reasoning here is to help users to protect their privacy and help them protect their personal data. Because really when you're talking about content blockers, you're talking about tracking blockers mostly these days. So Samsung's approach to this is to build an API but to allow the third-party developer community to build these blockers. And finally, before I hand over to my colleague, I want to mention that we are actually building a developer relations team based in London, which I'm going to be working with. And what we hope to be doing there is to support developers, to support developers in Europe and other places to be, you're going to see a lot of us speaking at conferences. You're going to see more people from Samsung Internet talking about progressive web apps, talking about push notifications, talking about web and VR, talking about all of these capabilities. And you're going to hopefully see us in more places around open-source projects, contributing to open-source projects, et cetera, stuff like that. OK, so with that, I'm going to hand over to my colleague, Jung Ki, who's going to talk with some more detail about the service worker. Yeah, thanks, Dan. Thanks, Dan. Hello, everyone. I'm Jung Ki-sung on Samsung Internet team. I'm working on the web platforms and standards. So we have talked a lot about service workers yesterday, so it's time to wrap up. So basically, service workers solve two essential problems. First of all, service worker solves this, li-fi. Service worker brings the reliability bits to web application and the development. And the second, service worker solves this one. Like, back in the days when we didn't have service workers, we actually did that with push API. So the push API tried to define this push event handler in a page, like navigator.setMessageHandler will set this push event handler. And then the event is kind of dispatched to this page. But when the page is closed, then the whole context is gone. So it wasn't possible, actually. And here's another example. The spec itself has been deprecated, but the alarm API and system applications working group, they try the same thing with that. Like, they define this on alarm handler in page context. So service worker just brings the background service context to web applications. So Samsung has contributed to service worker spec since around, like, November 2013. So it has been around more than two years. So we just worked it hard. And it was really a great experience to discuss about this great API with a group. And also, it's really great to be here while providing these APIs to enable PWA. And it has been one of the essential API to bring this happen. And well, not only the specs out of it, Samsung also committed to Chromium project. So we implemented and shipped quite a lot of features. Our contribution to Chromium is not really limited to service workers and the specs, but here's the list of features that we shipped. And also, I made a pro request to this service worker ready repository, but really had to do this earlier because we were there since this March. But just in time, it has been merged. And it's really happy to see our browser as a browser supporting service worker in this list. And here is the service worker feature status, release note for our 4.0 release. So basically, we provide the features based on Chromium 44 with some additions and changes. So please check this out in developer.samsung.com websites. And here's a demo. We have seen a lot, but I just want to show you how it works in Samsung Internet on the Galaxy phone. Yes, this is offline wiki. I try to search Gangnam style there. And the caching is just triggered on the page by user interaction. So this is one usage of service worker. And then it has shown up in the list of articles, cache it, and try to make sure this is working offline with the reliability bits. And opens up again, and it is just working there. And yes, and this is a first-class citizen to the native OS. So it's shown up in the test manager. So this has been possible due to a number of technologies, including service workers. So now let me just get down to more details about service workers, some key concepts. So let's wrap up. So basically, service worker is an event-based worker. So whenever functional events is triggered inside of browser internals, then browser spins off service worker. So supposing there is a resource request from the page, then browser spins up the service worker. And then in this on-fetch event handler, you as a developer have a chance to just look up local cache. And if there is a method response, then it can be responded to with the client right away. And when the event handling is just done, then browser automatically terminates the service worker. So let's compare the lifetime of a service worker to some other workers, like dedicated worker, for example. Dedicated worker is created by calling this constructor. Then browser creates a new thread, independent thread, to run this script. And the lifetime of this script is just bound to its parent client. So unless it calls the Terminate API, then it will leave up to when the page is closed. Now on the contrary, the service worker's lifetime is intentionally designed to be very short. So as you have seen from the figure in the previous page, service worker is just spinning off by some browser events. So let's say fetch event has occurred, then it creates an independent thread for service worker. And service worker is running and dispatching some functional event there. And then when the event handling is done, then service worker, the browser internal, terminates the service worker. And the same thing happens with a push API. Actually, browsers do all the smart things, like just keeping service worker alive until a sequence of events are being handled. But the basic concept of service worker lifetime is like this. And let me just talk a little bit about the spec itself. So here's a snippet of some spec text. And I wanted to talk about service worker registration and service worker concept. So this is some internal concept, internal slots of those objects. And service worker registration is a state that holds some multiple different versions of service workers. And it is keyed by scope URL. So there's installing worker associated with it and waiting worker and active worker. So when a service worker is being an active worker after the successful installation, then it starts to control the clients and dispatching a browser dispatch all those events to this active worker. And at the same time, a new service worker version can be installed in the background. And when the installation is successfully done without any error, then it's going to be a waiting worker. But it doesn't really take the place of active worker right away, rather than that it just waits until all the clients that are controlled by the previous active worker, the incumbent active worker, are being closed. Then the waiting worker will be the new active worker. And the service worker itself is running on the registering clients origin, basically. So there are those concepts implemented by browser inside. And this is the whole picture of all those implementations. So the upper part of this figure is a script surface that you, as a web developer, access to. Like there are service worker registration JavaScript and all the getters to get the active worker, installing worker, those things. But well, there are underlying browser internal implementations there, which implemented those internal concepts that I described, I mean, explained in the previous slide. So it all matches to those states. And whenever some events is triggered within browser, then the actual threads, I mean, independent thread is working. And then the event is being dispatched. And those states are kind of, those states can be accessed by the script surface. So this is like a big picture of the whole stack. And also, let's wrap up how to use service worker in a sequence. Like in order to exploit this, we surely have to register a service worker. The installation is triggered by this registration, register API. And then on install is getting dispatched by browser during this installation. And it is really a good place to pre-cache all the static resource. And when it becomes an active worker, then you can handle the functional events. And on activate is also a lifecycle event that is dispatched during the installation. And this is a place where you can just delete whatever cache objects that will not be used in the next version. And we also provide the update API. So you can explicitly call this. And also, browser triggers automatic update by every navigation and some functional events, like push event. So here's the sequence of registration operations, like from number one, number two, and number three. There are three register calls in a sequence. So with the first one, we create service worker registration in the map, with a scope being like slash bar. And the second one has different scope. So it creates another new registration. But third one has the same scope with the first one. So in this case, this service worker 2.js will take over the first one. And here's the installation process. I just wanted to explain how the state of those service workers in the registration changes. So when the install process or update process is triggered, then the first thing browser does is fetch this service worker script from the network and evaluate this script. So assuming there are three handlers, like on install, activate, and fetch defined by developer. But at this moment, the fetch event is not really being dispatched, because this service worker is not really an active worker yet. So it's in installing state. And then browser fires install. Then you can do those pre-cache in this install handler. And all these things, when all these things are successfully done without any error, then it's becoming a waiting worker, which is in install state. But still, this service worker is not really controlling any clients until those clients controlled by the incumbent service worker are closed. And when that happens, then browser dispatched this onactivated event. And from this moment, this service worker is being an active worker, a new worker. And then all the functional events are getting fired. And here's also an important concept to wrap up. Like there are some main resource requests and sub-resource requests. The main resource request is the page navigation or worker client creation. So service worker does this combatch with this main resource request. So if there's example.com slash index request, then we try to do this combatch here. So there's a service worker registration matched to this specific scope. And the service worker spins off. And we all do this stuff. Then this resource that returned by service worker is being the main resource for this page. And once this service worker is associated with this page, then the page just leaves with this service worker for its entire life. So if there's a sub-resource request to fetch an image while residing in slash image, slash flower, the PNG. And even though there is a registration that has a more specific scope with this resource, it just spins off service worker with whatever it is already associated. So it just uses sw.js, not the image slash sw.js. OK, so here are some patterns of APIs that we can look at. Like this InstaHandler provides the place where you can pre-cache all the static resource. So wait until it's an event to extend the lifetime of this event. And then you open up the cache and add all the stuff in the cache object. And this is another use case, like cache on user demand. So this is the case what you have seen in the offline wiki demo. So it just starts from the user interaction when the user clicks on some part of the element. Then we do some prevent default, the click event. And then open up the cache and fetch the dynamic contents. And then we'll just add those resources to cache. So it just starts from the page, not even started from service worker. And this one is more general offline first use case, what we have seen quite a lot. Like on fetch event, you can respond with some resource that is passed in this API. And what we do is like open cache object and then try to match the local cache first. And then if there is a response, then we just respond with that result. Otherwise, we go to the network and we'll update the cache and also respond to the client at the same time. And this is where you manage your cache versions, like on activate. Also, this is an extendable event. So you just extend the event and get all the cache objects there and the filter, whatever you will not really require for your next version of the service worker, then you will just explicitly delete all those objects. And this is a push API example. So with this one, also this functional event is an extendable event. So call wait until and then open up cache. Then fetch whatever data for this mailbox. Then this example just will do show notification with the first occurrence of this email list. And when user clicks on this notification, then you can do this like open window operation. So here's the obligatory, well, Jake Archibald picture. And you can check out all those use cases in offline Viki. This is great site. This is really obligatory material in different sense. So what comes next to PWA? So we are now here. And then, well, we kind of hear quite contentious discussion around the user experience about how user perceive PWA in a browser. So we are experimenting how to just enhance the user experience to this installation or KIP better. The KIP is a verb that Alex mentioned a year and a half ago. And I really like this verb, KIP, because the user just starts from his tab, her own tab, and then keep this app. And then it's just getting more capable applications. So that will be kind of an interesting discussion to just comment. And also, on the spec side, we are not stopping here. So we are trying to just finish the version one of service workers around the third quarter of this year. And at the same time, we are discussing about some new features for V2, like foreign fetch and cache API enhancement, those things. So well, I really want us to think about all this stuff and really want to make the web dominating mobile as well as in desktop world. So well, thank you for listening. And I'll hand it back to Dan. I've got now something that, now that you've had this kind of deep dive into service worker and how service worker works, I thought it would be good to kind of rise up for a second and have a bit of philosophy. And the kind of philosophy that I'm talking about is web philosophy. So by the way, if you haven't seen existential comics, I really recommend them. Go to existential comics and check it out. Very, very good stuff. So the part of web philosophy that I want to talk about is thematic consistency. I was involved in 2005 in creating something called the mobile web initiative. The mobile web initiative and the mobile web best practices that were produced from the working group that I chaired, which was the mobile web best practices group, were really from a different era of the mobile web. It was from an era where most phones did not have and could not have very capable browsers on them. They had compact HTML browsers. They had very, very cut down browsers. And we needed some rules to give to content providers to give them kind of best practices for how to build content in that environment. So many of those best practices actually don't hold true today. And I would argue probably aren't needed. We don't need that kind of thing today. However, there is one rule, which was our number one best practice that I think holds true today as much as it did in 2008. And that is the idea of thematic consistency. So to quote the best practice is to ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices. And this is something that we called the one web principle. So one web is a bit of a philosophical concept. It is not necessarily a technical concept, but it is something that arguably knits the web together. And it's based on the idea of the URL being the key technological or architectural element within the web. And I think this relates to something that I've been hearing about. I've been hearing a lot of questions from web developers who have asked, well, now that you're talking about progressive web apps and moving everything towards progressive web apps and offline first and all that kind of stuff, do we throw everything that we knew already about responsive web design out the windows? This is totally a new thing. And I would argue, and I think that we have to make this the case, that progressive web apps must be built on responsive web design principles. So this is something that's additive on top of something that we already know, which is how to build great responsive web applications, which is the current best practice around how to satisfy the thematic consistency best practice. And it's all about, in my view, respecting the URL. So it's about when you go to a certain URL, you know that you're going to get the same content. You know you're going to get something similar, something thematically consistent, no matter what device you go from, be it a phone, be it a PC, be it a tablet, be it a television, refrigerator, whatever you've got in front of you, you're going to get something that is consistent. And philosophy. OK, I've only got one more thing to talk about, and then you're not going to see me again. Well, you are going to see me for the panel. And that is web and VR. And that's something that Samsung is particularly interested in, because we have this thing called the Gear VR headset, which is basically like you take your Samsung phone, you plug it into the front. It's a bit more complex than Google Cardboard, because it also involves their extra sensors. There's a bit of a touchpad. But basically, it's the same kind of concept. And it's in partnership with Oculus. So what we've done is to produce a browser, which is actually a separate browser that sits within the Oculus environment within the Gear VR. And that is based on the same core. It's also service worker enabled. And a lot of the focus here is on providing a viewing experience for immersive content, for 360 degree content, that kind of thing. So we've enabled, by using specific video metadata for 3D content, for immersive content to be able to just come right up into the browser that's sitting within the VR environment. And we're doing this because we want to enable this kind of experience where you could, which I'm calling like a mixed browsing experience or a continuous experience, where you can be using your phone to do kind of regular browsing. You're reading a news article, for instance. You see that at the bottom of this news article, oh, there's a 360 degree video associated with this. Or there's an immersive experience associated with this. So being able to go straight from there, plugging the phone into the goggles, and actually experiencing that immersive experience, that's something that we want to enable. And that's built using this extra browser or this separate browser. But what we've enabled is this kind of experience where you can go straight from one into the other, and it goes straight to what you were looking at before. So I won't go into too much more detail on that because we're out of time. But in fact, I'm going to blow through this as well. The only other thing that I wanted to talk about is that we are working on a web VR specification with Google, with Mozilla. And that is enabling extra APIs, sensor APIs, and the ability to know whether or not your phone is hooked into such VR goggles. And all of that is being worked on in a W3C community group, which we helped to form. And hopefully we are going to be seeing a workshop coming up later this year, W3C Workshop on web and VR. So watch the space for that. So anyway, thanks very much for listening. And I'm going to hand back over to Paul.