Recently, Service Workers made quite some noise and people encourage to use this very newest technology on every website. But when I looked at the implementation and specification, I ended up having more questions than answers to it.

Note: This post is not a rant about Service Workers. I believe they are a great technology and help us as developers creating better services. This is just an expression of my initial thoughts as a browser user having a detailed view on this new technology.

A few weeks ago, I had a chat with Tobias Tom about Service Workers. He challenged it as we were talking about web performance, caching, and privacy. During that, we digged deeper into Service Workers and tried to find out how they are implemented currently in Chrome and Firefox. And for a feature that is available (partially) in stable versions of browsers, what I found out made me worrying about it.

First, it’s interesting to see that browsers have implemented a technology for which only a W3C editor’s draft is available on a personal github page by Alex Russell is available as “web standard”. It’s under heavy development and obviously misses quite some points. It seems I was wrong about no official standard being available because there is indeed a stable Working Draft spec. Thanks for point this out, Jake.

Permissions

The first thing I noticed after making sure that Service Worker are enabled (Chrome is behind flags) was that I found no user setting or any hint in the developer tools about service workers. From my first impression, I had expected to either get a notification (as it’s being done for geolocation or other APIs) or at least being able to debug it and see contents and details in the developer tools. Two points here:

• As a user I expected to be notified about a page wanting to store things for offline or later usage on my machine
• As a user I expected to be able to delete the cache of Service Workers and with it the Service Workers itself (this is not true for Firefox as of today)
• As a developer, I expect to be able to debug it and see Service Worker content in the developer tools in a dedicated view. This is not true as of today for Chrome and Firefox (although they claim support for this but it’s rudimentary and does not allow modifying the cache or similar things)
• As a specification reader, I expected the specification to contain something about permissions. As a matter of fact, neither the Permission API, User Notification API nor the word “permission” can be found in the spec as of today. The only thing that can be found is that there’s interest in making Web Notifications available to Service Workers so if a developer is responsible, he can ask for permission before starting the service worker offline action.

Concerns about Transparency and User Control

Currently, both Chrome and Firefox seem (I have no evidence on that, sorry) to use the generic browser cache for Service Workers. The problem with that is, I hadn’t expected this.

Firefox for example has the network settings view with settings for the Cache and a dedicated section about “Offline Web Content and User Data”, listing the permissions setting for that and the websites using this. However, websites using service workers are not listed nor affected by this setting. Going into the details, I found out that there is a dedicated Service Worker control page available under this URL: about:serviceworkers. This lists all the Service Workers that are registered. Unfortunately, a user is not able to unregister all of them at once—the cool thing is, it contains many details to find out what an active service worker is doing.

Chrome on the other hand, has changed this and does not offer any differentiation on that anymore. That means, you can only control Service Workers by deleting your entire browser cache. Fortunately, at least Chrome deletes also the service worker itself when doing that. You can keep track of Service Workers by typing in this URL into Chrome: chrome://serviceworker-internals/.

A Little Detail: Let’s just add a little detail on both of the internal browser control pages: None of them contains useful or semantic, let alone accessible markup here. So unless you’re able to see the page, that is completely useless. It’s also useless to parsers so I wasn’t able to write a script for Chrome that clears the workers as they use a span without a class or other reliable identifier as button here. Thanks for that, browser vendors!

Concerns about Storage Limits

So as the two big browser vendors that have implemented Service Workers so far agreed on using the generic browser cache for it, a user is out of control on what is stored on his/her device. That given, the only control is to limit the cache size—which is exactly what I’ve done to prevent Service Workers eating up my storage. The problem with that is, that by limiting the generic cache I fetch more data and create more traffic to servers.

So why did I limit my cache size manually? There is a simple few reasons for it:

1. I don’t want to let my browser eat up my disk space
2. There seems no limit what Service Workers can register to store offline per Service Worker. So any website I visit can store huge amounts of data in the background. This could include images, CSS, JavaScript, videos.
3. Ad providers or any malicious site can store JavaScript in Service Workers and might be able to track me and serve malicious code to me.
4. If someone compromises a usually trustworthy website, the attacker of course will register a service worker to be as persistent as possible in the user’s browser and can therefore alter the content of the website even if the server is not under his control anymore. Wanna know more about this? Yay, go here and to this PDF in Section 3.5.

Conclusion

Tobias immediately reflected on why Safari hasn’t started implementing Service Workers yet. We assumed, that as in the past, Safari cares about great user experience and therefore will only implement it if the permission issues are solved. Of course, this is only a vague assumption without any evidence here.

I really hope that no mobile browser will implement Service Worker without providing more control to the user here. And by raising these issues here, I want to ask the browser vendors and spec writers to fix that behavior before Service Worker become really popular.

Update 1

It seems I have offended people with my “badly researched” article. To be clear on that, this article may not be technically entirely correct – I said it before and can only repeat it. This article reflects my thoughts, my personal opinion and my open questions from what I know of Service Workers and from what I found out of using a browser and trying to change its settings (without opening developer tools or weird internal pages). It is a sharing of an experience as a normal web browser user that cares about his cache, privacy, security and storage quota.

Thankfully, Jake Archibald spend some time and replied to my article with some explanations. I also noted down additional thoughts as a comment over there after the new information I gathered from the gist.