Introducing Service Workers
For install conditions, a browser installs a service worker if
The browser supports service workers.
The browser loaded the web app using a TLS (HTTPS) connection or from the system’s localhost address (referring to the local device running the browser).
The web app loads the service worker code within the same context (from the same server location) as the web app for which it’s associated.
Unlike with web app manifest files, most modern browsers support service workers; you can check the current support matrix on Can I Use.2 As I write this, the following browsers support service workers: Chrome (Google), Edge (Microsoft), Firefox (Mozilla), Opera (Opera), and Safari (Apple). Many other browsers support them as well; check first if you know your app’s target audience prefers a specific browser that’s not in that list.
Depending on how web developers take advantage of service workers in their apps, service workers:
Cache app content. Google calls service workers programmable network proxies; as you’ll see in this chapter and the next, you have a lot of options for controlling which resources the browser caches and which ones are pulled from the server when requested by the app. You can even replace requested resources (files or data) dynamically at runtime using a service worker.
Perform background processing. Web apps use service workers to deliver background data synchronization and offline support. Service workers install in the browser, they’re associated with the web app, but they run in the browser’s execution context. This means they’re available to do work whenever the browser is open, even when the app is not loaded. You’ll learn more about this in Chapter 5, “Going the Rest of the Way Offline with Background Sync” and Chapter 6, “Push Notifications.”
Receive push notifications. With the right protocols and a backend server to send notifications, web apps use the background processing capabilities of service workers to enable the processing and display of push notifications sent to the app. You’ll learn more about this in Chapter 7, “Passing Data between Service Workers and Web Applications.”
The primary reasons browsers require a TLS connection to install and enable a service worker are those included in the bulleted list you just read through. Considering all you can do with the capabilities described in that list, the service worker has complete control over data coming in and out of the app. Browsers require the TLS connection to enforce that the web app and service worker load from the same location.
Without a TLS connection and the requirement that the service worker loads from the same context as the web app, hackers could compromise a site and load service worker code from another location and take complete control of the app. A rogue service worker could redirect all requests to alternate servers, capture auth and push tokens, and more.
Of course, service workers have limitations:
Service workers don’t run unless the browser is open. The web app doesn’t have to be open, but the browser does.
Service workers don’t have access to the web app’s document object model (DOM), but we’ll discuss workarounds for this in Chapter 7.
The first limitation may not be a big deal depending on the browser and operating system (OS). On many mobile devices, the browser always runs, so it’s there to run the service worker. On desktop systems, some browsers run in the background as well or can be configured to do so. Chrome exposes an advanced setting. Continue running background apps when Google Chrome is closed, as highlighted in Figure 3.2.
Figure 3.2 Chrome Advanced Settings
I’ll show you more about what service workers can do and how they do it as we work through the rest of the chapter.