5 ms·
Service Workers: an Introduction
- jonaf 10y agoThis 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 steal my passwords from LastPass, for example, without knowing it. The chain of vectors just feels really dangerous.
- chris_st 10y agoI think the line: > It's a JavaScript Worker, so it can't access the DOM directly. Instead, a service worker can communicate with the pages it controls by responding to messages sent via the postMessage interface, and those pages can manipulate the DOM if needed. gives me some hope that it's intended to be isolated from all other tabs (including the one that started it!). There will be bugs, of course, but it looks to me like they're starting from a secure position, which gives me hope.
- tree_of_item 10y agoI don't think those things run in the same process in Chrome, and Firefox is moving towards a multiprocess model as well.
- jahewson 10y agoSandboxing means that plugins are not running in the same process at all.
- tomcam 10y agoCan someone explain why this was downvoted?
- untog 10y agoFrom 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.
- z3t4 10y agothis seems unnecessary as you need a html file and browser to bootstrap anyway. There is more to it though, it can continue to run after the browser has exited and intercept push mesages.
- cproctor 10y agoOops. I thought this might be an attempt at rapprochement with their janitorial staffs. Perhaps the wrong nomenclature for our new era.
- crudbug 10y agoI haven't read the specs, can you spawn multiple service workers on a single page ? If yes, what are the security measures to stop a rogue site to blow up your browser ?
- Klathmon 10y agoOnly one service worker per scope, the newest kicks out any older ones.
- Eun 10y agoRegarding HTTPs: there is https://test.bi https://test.bi
- voltagex_ 10y agoIsn't this an egregious violation of most of the TOS / agreements for paid SSL certs?
- SimeVidas 10y agoNote that this is the low-level API. For most people, I think, the recommended approach is to use libraries instead. Google itself has released sw-toolbox and sw-precache. There’s also a web-push server module for push messages.
- Animats 10y agoW3C: "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-considerations https://www.w3.org/TR/service-workers/#security-consideratio... [2] https://alf.nu/ServiceWorker https://alf.nu/ServiceWorker
- asutherland 10y ago2 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 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1220747 if you want to follow-along, but start re-training your muscle memory now! :)
- Animats 10y agoSo Mozilla is making it harder for end users to find and kill service workers? The main difference between the TR and the suggested document is a weak "privacy" section, suggesting that the data stored by service workers locally should be flushed on user request. Mozilla currently does not allow service workers to run in incognito windows, which sort of complies with that.
- gfaure 10y agoChrome 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?
- untog 10y ago> 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.
- throwaway98237 10y agoYou 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.
- gaur 10y agoI clicked the link half-expecting to find an article about pink-collar jobs, but nope, just another badly named technical concept.
- voltagex_ 10y agoHow can I protect my browser against these things?