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.
Nice, thanks. While you indeed cleared up a few things for me (thanks here) I find it incredibly sad to see such a bad-worded, emotional reaction here. My post clearly pointed out questions and it’s really sad to get replies that let me seem to be the dumb person while you don’t even try to understand my point of view or position as a user here.
So, you still don’t tell me a place for the user but claim I’m spreading "FUD" here.
Speaking as developer here, I had expected a dedicated tab in the DevTools panel and no, getting the information via console is not what I expect (I require that actually). As you say,
chrome://serviceworker-internals/is not for public but internal usage and does not provide much value to a developer. What I expected was a tab that shows me the Service Worker script and the cached objects. But this one is really a minor concern of my article. – You haven’t removed any of my "FUD" here, whatever that means for you.That is not entirely true. As described in my article, Firefox for example shows me a detailed list and asks me for permission for localStorage. And while we’re here. So from your point of view it’s okay that Service Workers are failing as well regarding user experience just because previous APIs do so. Fine, that’s your point of view but please in this case don’t invalidate my point of view.
Wrong. This is only true for Chrome (maybe also for Opera or other Chromium forks).
I can only guess here because no one provides me a better explanation here. I assume this, because I can only empty it with the generic cache AS A USER. A USER doesn’t open the DevTools and empty single SWs here.
This is very funny. In one sentence you point me to this resource to debug things and here you say it’s for Chrome developers only while there is no other chance besides emtpying all caches to remove all(!) service workers. DevTools afaik are page-related.
Yes, thanks I know. I talked about CONTROL.
Nice but it doesn’t fix the issue that is described here. But yay, at least we have a log for it. I don’t understand why you can’t agree on this being a problem and this making a point why a user choice (wheter it’s a browser setting or a confirmation notification – I don’t care) could make sense.
Yes, on that’s definitely all mobile browsers etc. What’s your point here? That I have not researched every single aspect? Yes, that is what I wrote in the beginning of my post. My post just shares an OPINION and EXPERIENCE as a user. Do you think you make my experience better by saying I’m wrong and by mis-reading my sentences? I just don’t get what I’ve done to you personally to deserve such a bad written, offending answer. I’m out here.