"Service workers are basically app downloads that take place entirely at the provider's whim and under their control. Not only do we not know what the app does - we don't even know we're downloading it. Meanwhile, lawmakers think they saved online privacy with cookie banners."
Quote the term "service worker" to your average internet user, and they'll probably envisage some abused soul being repetitively ear-bashed by permanently angry customers in a call centre. But in the tech world, a service worker is also a particularly surreptitious facet of browser technology…
WHAT ARE SERVICE WORKERS?
Service workers are JavaScript programs which expand a simple web connection into a provider-controlled online/offline relationship. They're downloaded to and installed on the user's own device - often along with a raft of cached paraphernalia they usher through the door behind them - without consent or (in most cases) knowledge. The functionality of a service worker can be likened to that of an app. But an app is installed and controlled by you. The service worker is installed and controlled by a website or platform, behind your back. That's already a problem.
Service workers are capable of good things. For example, they run push notifications, and can allow you to continue interacting with a page when your internet connection temporarily cuts out. Particularly on mobile devices, the latter is undeniably useful - in some contexts legitimately a dependency from the user side. And service workers are registered and installed under strict conditions that only allow them a limited scope of operation, in conjunction with their source site.
For reference at this point I will also mention web workers, which are similar to service workers, but are used as background processors of resource-demanding tasks, as a means to take the weight out of foreground web processes like page-loading. Both service workers and web workers can create privacy issues, but it's the privacy implications of service workers I'm exploring in this post.
DISCLOSURE, OR THE LACK OF
One could argue that service workers are billed in privacy policies among the clutter of hidden surveillance-capable schemes evasively described as "other technologies" or "similar technologies". But one could also argue that service workers are not documented at all…
For example, the Eth Tech email provider Tutanota installs a service worker which dumps 28 scripts into the user's local cache. Email providers routinely drop service workers for notifications, continuity and the like, so this is nothing unusual. However, Tutanota's service worker is dumping a considerable volume of non-trivial code onto the user's device, and the only reference to any local dumps in Tutanota's Privacy Statement is…
"We do not use cookies."
Aside from being pretty disingenuous (since Tutanota literally uses a local storage component as a login cookie), this illustrates that some companies - even privacy companies - do not consider service workers or dark storage a necessary disclosure at all. Not even under the collective carpet-sweep of "other technologies".
Welcome to the under-the-radar world of service workers and dark storage.
SERVICE WORKER ARRANGEMENTS VS TRADITIONAL COOKIES
It's pretty clear even at a glance that service workers are a greater privacy threat than first-party text cookies. Both reside on the user's own device. But text cookies can only store static information, whereas service workers can proactively perform tasks.
The stupidity of a privacy law that says providers must disclose text cookies but not service workers, is roughly akin to a trespass law that says I must tell you if I drop a leaflet in through your open window, but not if I drop in a human being.
Another major difference between trad cookies and the service worker system is the volume and complexity of information being funnelled onto the user's device. Traditional cookies are by design small and simple. The service worker system, in contrast, can be extremely convoluted and difficult to audit, sometimes downloading three digits of scripts with all sorts of roles.
SERVICE WORKERS AS CLIENT SIDE SPIES
Often, one such role is offline tracking. Given the chance, a service worker is able to organise the tracking of what a user does offline, and send the information back to the source website when the user next visits the live page.
However, it should be stressed that the scope of this tracking is limited to interaction with the source website in an offline context. It doesn't mean the service worker can run round your drive gathering random information and then report it all to the provider. It can't do that. What it means is that if you close your internet connection whilst on the provider's page, and then continue to interact with that page (scroll it, click popovers, etc), then provided the service worker has cached a means to record those events, the service worker can feasibly send your in-page movements back to base when the internet connection is restored.
In short, with a service worker on your drive, you can't necessarily stop the site from monitoring your behaviour on its web page by disabling your internet connection for a while.
This gives the service worker huge value to trackers, because if a user is disabling their internet connection deliberately, it's probably because they're doing things on the page that they don't want the website to know about.
Consider, for example, some products on a shopping site, where a "See More" button has to be clicked to reveal important info. You want to look at the "See More" popover, but you don't want the site to know you're interested in that product, because shopping sites can play around with availability once they know what you want.
For instance, if you're looking at the most expensive option, they could hide a cheaper option that appears elsewhere on the site so that it never displays to you in future. That way, they hope, you'll buy the expensive version that first caught your attention. This is absolutely a real tactic in ecommerce. It's one of the reasons surveillance capitalism is so profitable and so ugly.
So you want to click that "See More" prompt and read the popover, but you don't want the site to know you've clicked it. You deliberately close your internet connection so the site can no longer see what you're clicking. The plan works perfectly. You get your further info offline and you shut down your browser. But for the site, this is really bad news. It's desperate to know which of those items you were interested in buying.
Luckily for the site, and unluckily for you, the service worker was able to put the crucial information into a storage file it set up on your drive. Now it only needs you to return to the site. When that moment arrives, the service worker will re-awaken, collect the info it stored, and send it straight back to the tracker. It's as if you never closed the connection at all.
It's easy to see from this example that although a service worker does not have the scope to work outside of its own source website, it can still operate very much as a disservice worker as far as the user is concerned.
LIMITING AND BLOCKING SERVICE WORKERS
Before you limit or block service workers, bear in mind that some services you're using may stop functioning without them. The most likely impact will be in desktop push notifications. In the private domain, I wouldn't want notifications popping up on the desktop, but in office environments they're often essential, and they depend on service workers to run. So as a first step, be sure to think about any types of messaging service you're using. Service workers don't affect your receipt of actual webmail. Only the notifications that extend outside the browser.
Don't care about push notications and you know your internet connection is reliable? Okay, so let's go…
Service workers are installed per browser, and isolated to that browser. So a service worker installed in Chrome would not have any impact on your activity in Firefox.
The absolute cast iron universal way to block this JavaScript-driven technology altogether is to do something I will probably keep repeating as a recommendation until the day I die… DISABLE. JAVASCRIPT.
Without JavaScript the service worker can't register or install, and that means it can't pump any scripts or other assets onto your drive, which in turn means the whole process breaks down. Not only are you blocking the service worker, you're also blocking whatever else it wanted to smuggle onto your system.
However, you may not have the option to disable JavaScript, since most logged-in scenarios have been reworked not to function without it. That includes many so-called "privacy" provisions such as various Fediverse social alternatives and the like. They will argue that their JavaScript is innocent, but that's not the point.
The point is that in taking away the option for users to disable JavaScript, they are contributing to the precise culture which has enabled browsers to kick their JS control under the rug on the basis that "everyone uses JS". Yes. Everyone uses it. Because they are FORCED to use it. If, as a tech provider, you made a decision to drop JavaScript-free compatibility (and this is the thing - they are consciously destroying compatibility that they already had), then you are not a real privacy advocate. Au contraire. You are helping to strangle privacy.
Rant over for now. So what steps can you take to limit or block service workers when you're forced to use JS?
HOW TO DISABLE SERVICE WORKERS IN FIREFOX AND ITS DERIVATIVES
In Firefox and its derivatives you can type about:config into the address bar, search for the parameters below and make sure they're set to False…
dom.serviceWorkers.enabled
dom.webnotifications.serviceworker.enabled
extensions.backgroundServiceWorker.enabled
This specifically disables service workers, but the parameters are buried among four and a half thousand developer-level settings which are not adequately explained, so I'm not giving Mozilla any special applause for "respecting privacy".
HOW TO DISABLE SERVICE WORKERS IN CHROME AND ITS DERIVATIVES
Chromium/Chrome has a more granular approach to service workers, and it recognises them as part of the cookie permissions regime.
Although you can't natively disable service workers specifically in Chrome, you can limit their potency, effectively block them on all domains you don't log into, study their presence in the actual user settings, and delete them. You can also prevent them from reinstalling after deletion, but not without an extension. I'll come to that…
If you want to declare war on service workers in Chromium/Chrome, start by going into the Settings, head down to the System category and switch off Continue running background apps when Chromium/Chrome is closed. This does not stop service workers from registering or installing, or even operating as such. It does, however, stop them running "off-page", which is where the worst of the privacy invasion takes place.
Because Chrome/Chromium browsers treat service workers as part of the cookie permissions regime, if you disable first-party cookies you also effectively disable service workers. So if you set up a selective first-party cookie arrangement as I described in the privacy guide, you can very heavily limit the number of sites that can drop service workers onto your device. Only the sites you grant permission to use first-party cookies will be able to run service workers.
If you completely clear your Cookies and other site data in Chrome or Chromium's Clear browsing data dialogue (from the Settings menu), all service workers and their assets will be deleted as part of the process. However, doing this will log you out of any sites you're logged into. If you want to be sure that all data from dark storage is gone, also delete the Cached images and files, which appears in the same dialogue. Solely deleting Cached images and files will not log you out of sites.
You can further minimise service worker installations in Chrome/Chromium by strictly limiting JavaScript permission to the pages that you must use, and which won't work without it. Unlike Firefox, Chrome natively lets you block all JavaScript and then re-enable it selectively, per domain - same as the cookies.
To do this in Settings, go to Privacy and security > Site Settings > JavaScript. Change the Allowed setting to Blocked. You can then add any domains you want to use JavaScript to the Allow list. Alternatively you can install the NoScript extension, taking note of the warning in my privacy guide. The uBlock Origin extension will also let you block all JavaScript and then allow it selectively. You'll have to go into uBlock's settings and tick the Disable JavaScript box though. Out of the box uBlock Origin allows JavaScript.
With cookie and JavaScript permissions granted sparingly in Chromium, you should only get a few service workers installed. And you can see, manage and delete the installed service workers in the Settings. You could click your way through the menus to find the relevant page, but it's easier just to type chrome://settings/siteData into the URL bar and go straight there. On the All cookies and site data page, you'll see a list of all the sites that have put things onto your device.
As you look down the list, you'll notice that under each domain name there's a documentation of what it's stored. It may just say "5 cookies", or there may be additional categories of data such as local storage, database storage and service workers. You can click into any of the domain tabs to see a more detailed list of exactly what they've dumped. See below, an example list for Twitter.com…
If a domain shows a service worker, you can just delete the service worker by hitting the X to the right of the individual list item, and leave the other items untouched. In privacy terms, it may also be worth deleting the database storage and local storage. Normally, sites will not log you out when you delete the database and local storage, but you might lose some site preference settings. The aforementioned Tutanota is one of the exceptions that will log you out when you delete the local storage. That's because it puts its login cookie in the local storage rather than storing it as an actual cookie.
Deleting the service worker(s) in Chrome's site data settings will not stop the site from installing a new service worker next time you visit. But…
There is a way you can block specific, unwanted service workers from re-installing in Chrome. You can use the logger in uBlock Origin to set a blocking rule targeted precisely at the inaugurating service worker script. Naturally, you need to know the name of the inaugurating service worker script before you can find it in the logger. You can find it like this…
Go to the site whose service worker you want to zap.
Open More tools > Developer tools from the main menu in Chrome or Chromium.
Hit the Application tab.
Now click on Service Workers in the left hand menu.
This will show you a JavaScript file name listed as the Source. I've marked it with a red arrow in the screen shot below…
Now you just look for that file name in the uBlock Origin logger, and block it as per the instructions in this tutorial. Close the site and delete the service worker from Chrome's settings as previously explained. It is now blocked and will not re-appear unless the provider changes the name of the source script.
All's well that ends well, but what a massive amount of hassle to prevent website owners from deciding what you should have on YOUR computer or device.
SIGNING OUT
Service workers are basically app downloads that take place entirely at the provider's whim and under their control. Not only do we not know what the app does - we don't even know we're downloading it. Meanwhile, lawmakers think they saved online privacy with cookie banners. We need some privacy lawmakers who understand technology.