You gotta see the humor in Google being of the opinion that a "service worker is a script". I mean, we've all kinda expected that Larry Page is under the assumption that we're all just subroutines running in his "matrix", but now it's official.
Service Workers: an Introduction
11–20 of 23 posts
Re: Service Workers: an Introduction
#12You gotta see the humor in Google being of the opinion that a "service worker is a script". I mean, we've all kinda expected that Larry Page is under the assumption that we're all just subroutines running in his "matrix", but now it's official.
I clicked the link half-expecting to find an article about pink-collar jobs, but nope, just another badly named technical concept.
Re: Service Workers: an Introduction
#13W3C: "Service workers create the opportunity for a bad actor to turn a bad day into a bad eternity."[1] With service workers, cross-site scripting vulnerabilities are forever.
Service workers install by drive-by, which is troubling. In Firefox, check "about:serviceworkers" to see what you have installed. Take a look. You probably have far more service workers active than you thought. There are supposed to be enough cross-site scripting restrictions to keep service workers contained to their origin domain, but some holes have been found. There was a successful service worker attack on Dropbox, since fixed. "If you run a site that serves user files with secret URLs from a shared domain, you need to look out for the Service-Worker: script HTTP header; if you see it, run for the hills."[2]
If an attacker can get one page loaded from a site being attacked, they then own all traffic between the user and the site. This has lots of attack potential.
[1] https://www.w3.org/TR/service-workers/#security-consideratio... [2] https://alf.nu/ServiceWorker
Re: Service Workers: an Introduction
#14Chrome also has chrome://serviceworker-internals.
I have no idea why Hampton Farms saw it fit to install a service worker. Furthermore, this isn't gated by a permission dialog like location services or plugin access?
Re: Service Workers: an Introduction
#15This seems like a security nightmare. I sincerely hope there's a way to just turn off "offline experience" in Chrome before service workers become widespread. The browser is a dangerous place to execute software. I suppose native apps can be just as insecure, but I worry about an ecosystem with many neighbors (web apps, extensions, plugins, add-ons, etc) running in the same process. It's much more likely one web app…
I don't think those things run in the same process in Chrome, and Firefox is moving towards a multiprocess model as well.
Re: Service Workers: an Introduction
#16W3C: "Service workers create the opportunity for a bad actor to turn a bad day into a bad eternity."[1] With service workers, cross-site scripting vulnerabilities are forever. Service workers install by drive-by, which is troubling. In Firefox, check "about:serviceworkers" to see what you have installed. Take a look. You probably have far more service workers active than you thought. There are supposed to be enough c…
2 quick hopefully informative nits:
It's better to consult the living standard of the editor's draft over the TR ("TR is for the TRash" as they say). The security section has been fleshed out a lot, for example: https://w3c.github.io/ServiceWorker/#security-considerations
In Firefox, about:serviceworkers is in the process of being replaced by about:debugging. The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1220747 if you want to follow-along, but start re-training your muscle memory now! :)
Re: Service Workers: an Introduction
#17This seems like a security nightmare. I sincerely hope there's a way to just turn off "offline experience" in Chrome before service workers become widespread. The browser is a dangerous place to execute software. I suppose native apps can be just as insecure, but I worry about an ecosystem with many neighbors (web apps, extensions, plugins, add-ons, etc) running in the same process. It's much more likely one web app…
Can someone explain why this was downvoted?
Re: Service Workers: an Introduction
#18Chrome also has chrome://serviceworker-internals. I have no idea why Hampton Farms saw it fit to install a service worker. Furthermore, this isn't gated by a permission dialog like location services or plugin access?
> this isn't gated by a permission dialog like location services or plugin access?
No. The justification is that you'd need to prompt for additional permissions to do almost anything with a service worker, other than react to fetch event.
Re: Service Workers: an Introduction
#19This seems like a security nightmare. I sincerely hope there's a way to just turn off "offline experience" in Chrome before service workers become widespread. The browser is a dangerous place to execute software. I suppose native apps can be just as insecure, but I worry about an ecosystem with many neighbors (web apps, extensions, plugins, add-ons, etc) running in the same process. It's much more likely one web app…
From my understanding, the service worker doesn't live indefinitely in the background - it reacts to events. So without additional permission prompts, it will only react when you load a page that's within the service worker scope. So I'm not sure what additional security concerns there are.
Re: Service Workers: an Introduction
#20Regarding HTTPs: there is https://test.bi
Isn't this an egregious violation of most of the TOS / agreements for paid SSL certs?