ServiceWorker's Link rel=serviceworker leads to botnet-like persistent JS worker

https://bugs.chromium.org/p/chromium/issues/detail?id=662443

https://www.chromium.org/blink/serviceworker/service-worker-faq

It isn't clear to me whether there are similar or other issues in Mozilla's implementation, but I'll point out these:

about:serviceworkers
about:debugging#workers

 

I keep workers and serviceworkers in FF's about:config set to false as default. I have to enable some of them when it comes to using websites such as Mega. There are others, but they slip my mind at the moment.

 

@marzametal: Exactly which prefs do you set to false? Is that all you do?

I ask because I just ran a few simple tests using FF 50 portable and the results were not what I hoped for. My test page silently (why is this possible?) installs a ServiceWorker which generates a mock response for $testUrl and spits out a few console messages while doing so. Test sequence:

1. Loaded the test page and verified that the ServiceWorker was installed
2. Loaded $testUrl and verified the ServiceWorker executed and provided its mock response.
3. Set dom.serviceWorkers.enabled to false.
4. Verified that about:serviceworkers showed "Service Workers are not enabled".
5. Loaded the test page, which reported that navigator.serviceWorker is not available
6. Navigated to $testUrl again and the ServiceWorker executed and provided its mock response.
7. I fully restarted Firefox.
8. Navigated to $testUrl again, and the ServiceWorker executed and provided its mock response.

IOW, it appears that the logical preference (dom.serviceWorkers.enabled) doesn't fully disable ServiceWorkers. The behavior I saw suggests it may only disable the navigator.serviceWorker API which is used to register/unregister/etc them.

The Clear All History feature, with the Browsing & Download History checkbox checked, did remove the ServiceWorker. As did the Unregister button in about:serviceworkers.

PS: Even though I think it is for WebWorkers rather than ServiceWorkers, I tried setting dom.workers.enabled to false too. Same results as above.

 

@TheWindBringeth
I am using FF 49.0.2 full install.

I have the following altered in about:config (I swapped all false to "true", and all numerical values to "0" (zero))
dom.serviceWorkers.enabled
dom.serviceWorkers.idle_extended_timeout
dom.serviceWorkers.idle_timeout
dom.serviceWorkers.openWindow.enabled
dom.workers.enabled
dom.workers.maxPerDomain <--- in 49.0.2, this value was originally 50. It seems severely high to me.

Also I have noticed from time to time, some quirks in relation to about:config entries. For example, setting browser.cache.disk / memory / offline.enable to false works, but once in a while it doesn't (...on my side anyway). So I had to set all related values to zero for entries such as browser.cache.disk.max_entry_size etc...

Upon reading your latest post, I had another look and noticed another entry which was not there yesterday (I was not drunk, but who really knows...):
dom.webnotifications.serviceworker.enabled

I have also set this to false as of now... I am not sure of the differences between FF portable and FF installed. Does portable respect the same OS rules as installed? (eg: OS permissions are the same for portable / installed)

EDIT: "My test page silently (why is this possible?) installs a ServiceWorker..."... is it a physical installation into a FF directory?

 

@marzametal: Thank you. I was going to look at dom.workers.maxPerDomain, but as you noticed I learned it was dropped.

I can't rattle off a good answer to "how is FF portable different from FF installed". I do most of my testing with a portable version, then when it seems appropriate I followup by testing with an installed version. I'm not over to FF 50 yet.

Firefox decides where and how ServiceWorkers will be stored, and I think that is in the profile and/or cache. I don't know more than that at this point.

 

@TheWindBringeth - Woe is me... for 4 minutes, I was trying to get your handle to pop up after the @... then it dawned on me I was referring to you as TheWindMan! hahaha overdose on baked beans

Maybe we can narrow down the storage locations with a bit of testing... such as disabling disk cache, memory cache and offline cache. This would, in theory, remove cache from the equation. All that is left is the profile folder and/or install folder. Further monitoring could be applied via apps that monitor for newly created files and modified files on system or USB stick.

Maybe... lol