My reply to https://helloanselm.com/2016/open-service-worker-questions/, which sets a new record for false statements per word.
The first thing I noticed after making sure that Service Worker are enabled (Chrome is behind flags)
No they're not. They've been in stable for over a year now.
was that I found no user setting or any hint in the developer tools about service workers
There's a service worker panel in the sources tab and in the resources tab. There's also chrome://serviceworker-internals/. The script also appears in the context dropdown (as iframes do). The script itself also appears in the sources panel. You can also type navigator.serviceWorker.controller into the console to inspect the controlling service worker for the page.
You would have found out about all this with very little effort.
It's slightly annoying that there's this amount of FUD already.
I had expected to either get a notification (as it’s being done for geolocation or other APIs)
Permission for what? When you register for a service worker it start up a script in another thread. In terms of privacy and security this is the same as new Worker and new SharedWorker.
The service worker can intercept requests, but that's no different in terms of privacy and security because the page itself can already make requests wherever it wants.
The cache API is entirely independent, you don't need a service worker to use it. But even then, it can't store anything different to IndexedDB except opaque responses, which aren't a security or privacy issue. The cache API is just storage that's optimised for matching and streaming.
or at least being able to debug it and see contents and details in the developer tools
"Cache Storage" is right there in the resources panel, along with all of the other storages.
As a user I expected to be notified about a page wanting to store things for offline or later usage on my machine
Between appcache, localstorage, indexeddb, cookies, even http caching, that ship sailed years ago.
As a user I expected to be able to delete the cache of Service Workers and with it the Service Workers itself
It can be cleared at a granular level within devtools, or you can clear it using the usual "clear browser data" dialog.
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 already there, as I said.
there’s interest in making Web Notifications available to Service Workers
Not only interest, this has been developed and shipped in both Chrome and Firefox. It's been shipped for months.
Currently, both Chrome and Firefox seem (I have no evidence on that, sorry) to use the generic browser cache for Service Workers.
They don't. What makes it seem like this? Why would it matter?
you can only control Service Workers by deleting your entire browser cache
Not true. They're all over devtools and chrome://serviceworker-internals/. As durable storage lands and matures, we'll be able to explain to users which origins they have indicated desire to keep.
You can keep track of Service Workers by typing in this URL into Chrome: chrome://serviceworker-internals/.
Wait, you knew this? Why did you just say it wasn't surfaced?
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.
It's an internal debug page intended for Chrome developers. Sure it'd be nicer if were better design in terms of markup and visual, but the friendly face of this stuff is devtools.
So as the two big browser vendors that have implemented Service Workers so far agreed on using the generic browser cache for it
A fact you made up, with no evidence…
a user is out of control on what is stored on his/her device
Storage usage appears in the site data menu.
which is exactly what I’ve done to prevent Service Workers eating up my storage.
Service workers have no special rights to storage over indexeddb, localstorage etc. If storage limits are hit, origin storage is cleared across sites (unless the origin is marked as durable).
There seems no limit what Service Workers can register to store offline per Service Worker
Untrue. Goes in the same bucket as all origin storage (IDB, localstorage etc).
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.
Already true with indexeddb, localstorage, cookies, http cache etc etc.
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
This is why we have strict rules regarding the location and serving of the service worker. It needs to be same origin, have a valid JS content type, and it cannot control anything outside of the path it's contained in.
Service worker script requests also have a header (step 8) so they can be identified in logs, so you can deal with it if the worst happens. If that happens, all these shitty planets align, and it's served with a max-age of > 1 day, that service worker will live for one day at most.
Of course, this is only a vague assumption without any evidence here.
At last, a true statement.
I really hope that no mobile browser will implement Service Worker without providing more control to the user here
Oh no, back to the untruths. Already implemented and shipped in Chrome, Firefox, Opera.
Yes you can control it there too. Please take a look.