Live data from Hacker News

ServiceWorker's Link leads to botnet-like persistent JavaScript worker

bugs.chromium.org

1–8 of 8 posts

Re: ServiceWorker's Link leads to botnet-like persistent JavaScript worker

#4
You can see what service workers are registered here:

chrome://serviceworker-internals/

Frankly, I'm tempted to label the whole notion of a remote-installing auto-updating local proxy as a misguided antifeature, but I honestly don't know enough about it. What was wrong with app caching?

Re: ServiceWorker's Link leads to botnet-like persistent JavaScript worker

#5
post #4

You can see what service workers are registered here: chrome://serviceworker-internals/ Frankly, I'm tempted to label the whole notion of a remote-installing auto-updating local proxy as a misguided antifeature, but I honestly don't know enough about it. What was wrong with app caching?

You mean AppCache?

Re: ServiceWorker's Link leads to botnet-like persistent JavaScript worker

#6
post #4

You can see what service workers are registered here: chrome://serviceworker-internals/ Frankly, I'm tempted to label the whole notion of a remote-installing auto-updating local proxy as a misguided antifeature, but I honestly don't know enough about it. What was wrong with app caching?

You mean AppCache?

Sort of. I meant caching apps, of which AppCache is an implementation.

Re: ServiceWorker's Link leads to botnet-like persistent JavaScript worker

#8
post #6

Earlier quoted context omitted.

You mean AppCache?

Sort of. I meant caching apps, of which AppCache is an implementation.

It's not dynamic and doesn't even allow wildcards. So, you have to use hashes given that opening /details?id=123 won't be served from the cache even if you have everything on the client side to construct that page. Most people just cache /details and navigate to /details#id=123. I think if appcache was made a little more developer friendly, the need for service workers would seriously be reduced.